KANSAS EDI TRAINING SEMINAR

1.

3. David Sprick Research AnalystDivision of Workers Compensation Kansas Department of Human Resources

4. Alan Stanton Research AnalystDivision of Workers Compensation Kansas Department of Human Resources

5. Sharon MarionEDI Coordinator for KansasBridium Inc.

6. WHAT IS THE EDI PROCESS? Submission of First Reports of Injury (FROI) and Subsequent Reports of Injury (SROI) From Trading Partners to the Kansas Division of Workers Compensation Through its application service provider (Bridium Inc.) In the IAIABC Electronic Data Interchange (EDI) format In a manner as prescribed by the Division�s EDI Implementation Guide

7. Morning Session10:00AM Welcome and Introductions 10:10AM Statute & Reporting Overview �10:50AM Break �11:10AM EDI Overview12:00PM Lunch (on your own)

8. AGENDA Afternoon Session1:15PM Implementation Requirements2:15PM How to Get Started Technology Methods3:15PM Question session

10. STATUTORY OVERVIEW Current Reporting Requirements Reporting Option as of 11/15/03 Compliance Confidentiality

11. 7-8 CURRENT REPORTING REQUIREMENTS K.S.A. 44-557(a) Employers or agents must send reports on 1101-A form to KDWC within 28 days of knowledge for injuries beyond remainder of �day, shift or turn� K.S.A. 44-557a(c) Insurers or agents must report closed claims data to KDWC on proprietary software, on the date provided by KDWC

12. 7 REPORTING OPTION as of 11/15/2003 K.S.A. 44-557a (b): Insurers may submit claims information by IAIABC�s EDI Release 1 as a substitute for Closed Claims data Regulation K.A.R. 51-9-17 (1/1/2004) Allow EDI First Report of Injury to be considered same as 1101-A form Stop paper reporting

13. EDI First Report of Injury (FROI) Submit to KDWC within time period specified in Kansas EDI Implementation Guide (28 days) EDI Subsequent Report of Injury (SROI) Submit to KDWC within time period specified in Kansas EDI Implementation Guide REPORTING OPTION as of 11/15/2003

14. 22-24 REPORTING OPTION as of 11/15/2003 Employer/carrier may continue to report on K-WC 1101-A to Division Employer/carrier may continue to report claims study requirement via Division software Employer/Carrier must continue to submit all medical fee data to Division (EDI program constitutes no change to medical fee requirements)

15. 22 EXISTING and EDI REPORTING COMPARISON

16. EXISTING REPORTING Carrier generates or forwards paper 1101-A to state, or reports to TPA which then generates or forwards paper 1101-A to KWC Self-insured employer reports to TPA or sends paper 1101-A directly to state Duplicates created when both employer and carrier or TPA send paper 1101-A to state Insurer or TPA selects cases from prior year to report using proprietary OCC (now CCS) software

17. EDI REPORTING Carrier translates report from employer into electronic report to send directly to KWC�s EDI vendor or reports to TPA which then generates or forwards electronic report to KWC�s EDI vendor Self-insured employer reports to TPA or sends electronic report directly to KWC�s EDI vendor Vendor edits reports, acknowledges back electronically to sender, and forwards acceptable reports to KWC

18. EDI REPORTING (contin.) No duplicates allowed If selected to report under CCS program prior to approval for production status under EDI program, insurer or TPA may report, using IAIABC EDI standard, those claims that would have otherwise reported using proprietary CCS software

19. 8-9 COMPLIANCE Failure to Submit Reports in Timely Fashion OR Failure to meet Data Quality or Technical Standards May result in revocation of EDI Participation and/or Fines and Penalties

20. 10 CONFIDENTIALITY K.S.A. 44-550b Workers Compensation records are open records except for accident reports, medical records and form 88's (not filed with the Division since 1994) and social security numbers WC records are open to the following: Employer after a job offer Employer and insurance company and their representatives when an employee files for benefits State and Federal Agencies for investigation of Fraud Upon order of a court of competent jurisdiction

22. EDI OVERVIEW What is EDI? What is the IAIABC? How does Kansas EDI work?

24. EDI IS Electronic Data Interchange = Exchange of business documents in a non-paper (electronic) environment

25. EDI is... Standardized business practices which permit the flow of information between organizations without human intervention. System-to-system communications. Technology for cross-organizational exchange of standard documents in a machine readable and universal format. EDI is taking data or information you already have and already send to others, or data or information you need or want to have and crafting an electronic means of converting that data or information into an electronic form, or translating it from one electronic form to another, according to certain rules or standards, and sending and receiving that data or information according to other rules. It�s taking an established need for data or information and traditional methods of exchanging that information, traditional ways of doing business, and translating those methods into electronic form, so that one entity�s computer system talks to the other entity�s computer system, translating documents into a format that can universally be read by machines.EDI is taking data or information you already have and already send to others, or data or information you need or want to have and crafting an electronic means of converting that data or information into an electronic form, or translating it from one electronic form to another, according to certain rules or standards, and sending and receiving that data or information according to other rules. It�s taking an established need for data or information and traditional methods of exchanging that information, traditional ways of doing business, and translating those methods into electronic form, so that one entity�s computer system talks to the other entity�s computer system, translating documents into a format that can universally be read by machines.

26. EDI goes back about 35 years, when the transportation industry (rail, ocean, air, and motor) realized that documentation needs were slowing shipments down (RFQs, Quotes, Purchase Orders, Order Statuses, Material Releases, Invoices, Advance Shipping Notices, Way Bills, Bills of Lading, Shipment Statuses, Freight Bills). In 1968, the TDCC (Transportation Data Coordinating Committee) formed, composed of the various transportation sectors as well as shippers, brokers, customs, and bankers. In 1975 they released the first EDI standard�the Rail Transportation Industry Application. In 1978, the American National Standards Institute (ANSI) formed the X12 Committee to use the work of the TDCC to build standards that could be used by any industry. Retail grocers began using EDI in 1981, and in the following year the warehousing industry followed suit. In 1988 automotive manufacturers began shaking up the industry by demanding that suppliers use EDI or lose business. And EDI has continued to grow from there.EDI goes back about 35 years, when the transportation industry (rail, ocean, air, and motor) realized that documentation needs were slowing shipments down (RFQs, Quotes, Purchase Orders, Order Statuses, Material Releases, Invoices, Advance Shipping Notices, Way Bills, Bills of Lading, Shipment Statuses, Freight Bills). In 1968, the TDCC (Transportation Data Coordinating Committee) formed, composed of the various transportation sectors as well as shippers, brokers, customs, and bankers. In 1975 they released the first EDI standard�the Rail Transportation Industry Application. In 1978, the American National Standards Institute (ANSI) formed the X12 Committee to use the work of the TDCC to build standards that could be used by any industry. Retail grocers began using EDI in 1981, and in the following year the warehousing industry followed suit. In 1988 automotive manufacturers began shaking up the industry by demanding that suppliers use EDI or lose business. And EDI has continued to grow from there.

27. IAIABC EDI Project History IAIABC began standardization of states� workers comp paper forms during the 1950s IAIABC began researching electronic transmission during the 1980s IAIABC developed EDI reporting standards in the 1990s 1990, IAIABC membership adopted the IAIABC Statistics Committee�s proposal to develop standards for communicating data electronically between providers, payers and state administrators via EDI. A workers compensation organization known as the IAIABC began an attempt 50 years ago to take the forms used by each of the 50 states and create a single set of forms that could be used by all states. 40 years later the organization looked at translating those forms into an electronic format culminating in the development of two sets of standards in the last 10 years.A workers compensation organization known as the IAIABC began an attempt 50 years ago to take the forms used by each of the 50 states and create a single set of forms that could be used by all states. 40 years later the organization looked at translating those forms into an electronic format culminating in the development of two sets of standards in the last 10 years.

28. The effort to develop an electronic standard involves assembling the right team of players: the states, the insurers, the claims administrators, and the service providers.The effort to develop an electronic standard involves assembling the right team of players: the states, the insurers, the claims administrators, and the service providers.

29. Asking the Right Questions... What Should We Be Collecting? Why Do We Need It? How Do We Use It? Who Should We Be Asking For It? When Are We Getting Duplicates? How Can We Make It Easier? It means looking at all of your business documentation processes and business practices to see where you could increase efficiency and reduce human involvement (and the associated risk for error) by adopting an electronic format for data flows. It means asking critical questions to identify your true needs and reduce waste and unnecessary effort. It means asking WHAT----WHY----HOW----WHO----and WHEN.It means looking at all of your business documentation processes and business practices to see where you could increase efficiency and reduce human involvement (and the associated risk for error) by adopting an electronic format for data flows. It means asking critical questions to identify your true needs and reduce waste and unnecessary effort. It means asking WHAT----WHY----HOW----WHO----and WHEN.

30. In workers compensation, for example, we would start by looking at what reports we currently get and what we use them for. First Reports of Injury are generally used to get basic data about how many and what types of claims occur each year, and what are the hazards that employers need to focus their safety efforts on. Continued reporting on the claim, known as subsequent reports, provides more detail, updates us on the status of individual claims, and provides the data that legislators and cost accountants are most interested in�how much is being paid out in benefits?In workers compensation, for example, we would start by looking at what reports we currently get and what we use them for. First Reports of Injury are generally used to get basic data about how many and what types of claims occur each year, and what are the hazards that employers need to focus their safety efforts on. Continued reporting on the claim, known as subsequent reports, provides more detail, updates us on the status of individual claims, and provides the data that legislators and cost accountants are most interested in�how much is being paid out in benefits?

32. There are three types of advantages to using EDIThere are three types of advantages to using EDI

33. Why EDI?Quantifiable Benefits Eliminates delays due to rekeying data Eliminates errors due to rekeying data Eliminates time spent in non-productive human-to-human error resolution (e.g., telephone tag) Eliminates paper handling, filing, storage, and mailing costs Quantifiable benefits�those you can measure�include getting rid of waste and improving accuracy: No double entry of data�the source enters the data and those who receive it simply store it, saving data entry time, reducing the risk for data entry errors, and reducing time spent chasing errors down. No paper means reduced storage space and space costs, no filing time, reduced �mailing� costs, fewer paper cuts, and more trees.Quantifiable benefits�those you can measure�include getting rid of waste and improving accuracy: No double entry of data�the source enters the data and those who receive it simply store it, saving data entry time, reducing the risk for data entry errors, and reducing time spent chasing errors down. No paper means reduced storage space and space costs, no filing time, reduced �mailing� costs, fewer paper cuts, and more trees.

34. Why EDI?Strategic Benefits Improves the quality and speed of operations Reduces operating costs Improves trading partner relations by assisting in reduction of their costs & improving operations Improves forecasting and planning through improved timeliness of reporting information Refocuses employee resources on more productive business activities EDI makes your business processes more efficient, but just as important, it makes the business processes and practices of all parties involved more efficient. In itself, this can boost goodwill among all, improving relationships among organizations as each begins to realize the savings in costs, the improvement in quality of operations, and enhanced productivity of employees.EDI makes your business processes more efficient, but just as important, it makes the business processes and practices of all parties involved more efficient. In itself, this can boost goodwill among all, improving relationships among organizations as each begins to realize the savings in costs, the improvement in quality of operations, and enhanced productivity of employees.

35. Why EDI? Unquantifiable Benefits Changed business processes Changed business relationships Changed business perspectives EDI presents many opportunities for change and growth in the organization.EDI presents many opportunities for change and growth in the organization.

36. EDI continues to evolve to meet the need for better data. States are grappling with legislative mandates for reliable and accurate data on the benefit and administrative cost drivers for the workers compensation system. Everywhere the lack of uniform rules, forms, and terminology hampers communication. As demands for information increase, so does the volume of paperwork.EDI continues to evolve to meet the need for better data. States are grappling with legislative mandates for reliable and accurate data on the benefit and administrative cost drivers for the workers compensation system. Everywhere the lack of uniform rules, forms, and terminology hampers communication. As demands for information increase, so does the volume of paperwork.

37. WORKERSCOMPENSATION EDI The IAIABC is an organization which started in 1914 whose members at that time were states only. The organization has since evolved to encompass all types of entities that are involved in workers compensation. Only one of its thrusts is in promoting EDI standards.The IAIABC is an organization which started in 1914 whose members at that time were states only. The organization has since evolved to encompass all types of entities that are involved in workers compensation. Only one of its thrusts is in promoting EDI standards.

38. WHAT IS THE IAIABC? International Association of Industrial Accident Boards and Commissions IAIABC stands for the International Association of Industrial Accident Boards and CommissionsIAIABC stands for the International Association of Industrial Accident Boards and Commissions

39. IAIABC INVOLVEMENTWITH EDI Acts as a workers compensation standards organization Members include state jurisdictions, carriers, claim administrators, employers, vendors, and other workers comp organizations Works cooperatively to implement electronic standards in both flat file and ANSI X12 formats As you saw on an earlier slide, the IAIABC promotes the use of EDI standards�in fact, it sets the standards. The IAIABC�s members are the government bodies involved in workers compensation, and associate members include insurers, TPAs, self-insured employers and group pools, service vendors, and other industry-related organizations and individuals. Some of the standards have been developed to allow the use of either of two types of file formats, which I will cover in a bit more detail later on.As you saw on an earlier slide, the IAIABC promotes the use of EDI standards�in fact, it sets the standards. The IAIABC�s members are the government bodies involved in workers compensation, and associate members include insurers, TPAs, self-insured employers and group pools, service vendors, and other industry-related organizations and individuals. Some of the standards have been developed to allow the use of either of two types of file formats, which I will cover in a bit more detail later on.

40. WORKERS COMPENSATION EDI Here�s how EDI works in workers compensation: An employee gets injured on the job Gets medical treatment from a doctor or hospital or physical therapist The providers send bills to whomever is paying on or administering the claim The employer sends an accident report, what is known in EDI as a First Report of Injury Then documentation is sent to the state agency overseeing the work comp processHere�s how EDI works in workers compensation: An employee gets injured on the job Gets medical treatment from a doctor or hospital or physical therapist The providers send bills to whomever is paying on or administering the claim The employer sends an accident report, what is known in EDI as a First Report of Injury Then documentation is sent to the state agency overseeing the work comp process

41. IAIABC EDITRANSACTIONS First Report of Injury Subsequent Report of Injury Medical Bills Proof of Coverage Detailed Acknowledgment There are several types of transactions under the workers compensation EDI standards. First Report of Injury refers to a group of transactions that occur at the early stages of claim processing that typically report the entities involved, and describes the accident and resulting injuries. Subsequent Report of Injury refers to a group of transactions that report claim processing changes to, or current totals of benefits paid on a claim. Medical bills is a group of transactions that provide details on medical billing on a claim. This transaction is not scheduled for use in Kansas yet. Proof of Coverage is a group of transactions that provide verification of employer coverage under a policy. Detailed Acknowledgment is a group of transactions that provide verification of receipt by the state of a transmission from a data sender. In addition, the acknowledgment provides information on any errors the receiver found in the data.There are several types of transactions under the workers compensation EDI standards. First Report of Injury refers to a group of transactions that occur at the early stages of claim processing that typically report the entities involved, and describes the accident and resulting injuries. Subsequent Report of Injury refers to a group of transactions that report claim processing changes to, or current totals of benefits paid on a claim. Medical bills is a group of transactions that provide details on medical billing on a claim. This transaction is not scheduled for use in Kansas yet. Proof of Coverage is a group of transactions that provide verification of employer coverage under a policy. Detailed Acknowledgment is a group of transactions that provide verification of receipt by the state of a transmission from a data sender. In addition, the acknowledgment provides information on any errors the receiver found in the data.

42. IAIABC IMPLEMENTATION GUIDE Data Dictionary File Layouts (Flat File & X12) Hard Copies Scenarios Code Lists Decision Table Templates (Event, Element Requirement, and Edit) The implementation guide developed by the IAIABC contains many generic components but also definitions and standards that a state may hold a reporting entity to that are not in the state�s own implementation guide. The data dictionary defines and describes each field�data element�that may be found in a report. File layouts are tables or lists showing the composition and structure of the file formats that can be used. There are two type of electronic file formats promoted by the IAIABC: flat file and ANSI X12; I will discuss those in more detail later. Hard copy (printed) versions of the reports are also available for states that want paper reporting to follow the same standards as electronic reporting. Scenarios show how transactions can or should be used for various events in the situations that commonly occur in claims and claim processing. Code lists have been developed or adopted to use in describing injuries, types of benefits, types of reports, or many other factors where use of a code can simplify and shorten the length of a report. Tables have been designed for specifying which reports will be accepted, whether and when individual data elements are required, and how the data will be processed to ensure that it meets certain standards. The tables in the IAIABC guide are templates available for states to individually modify to suit their own data collection needs.The implementation guide developed by the IAIABC contains many generic components but also definitions and standards that a state may hold a reporting entity to that are not in the state�s own implementation guide. The data dictionary defines and describes each field�data element�that may be found in a report. File layouts are tables or lists showing the composition and structure of the file formats that can be used. There are two type of electronic file formats promoted by the IAIABC: flat file and ANSI X12; I will discuss those in more detail later. Hard copy (printed) versions of the reports are also available for states that want paper reporting to follow the same standards as electronic reporting. Scenarios show how transactions can or should be used for various events in the situations that commonly occur in claims and claim processing. Code lists have been developed or adopted to use in describing injuries, types of benefits, types of reports, or many other factors where use of a code can simplify and shorten the length of a report. Tables have been designed for specifying which reports will be accepted, whether and when individual data elements are required, and how the data will be processed to ensure that it meets certain standards. The tables in the IAIABC guide are templates available for states to individually modify to suit their own data collection needs.

43. Key Components of EDI Hardware/Software Communications Standards Courage To have a successful EDI program, you have to have four key components: An electronic data platform An electronic data transmission method Rules to go by Just as success in invention is 99% perspiration, 1% inspiration, success in EDI is 99% courage, 1% preparation. Even though a lot of preparation is needed, courage is necessary every step of the way. Now I don�t want to scare you off, but it does take a lot of courage. I�ll discuss that more a little later.To have a successful EDI program, you have to have four key components: An electronic data platform An electronic data transmission method Rules to go by Just as success in invention is 99% perspiration, 1% inspiration, success in EDI is 99% courage, 1% preparation. Even though a lot of preparation is needed, courage is necessary every step of the way. Now I don�t want to scare you off, but it does take a lot of courage. I�ll discuss that more a little later.

44. STANDARDS National standards allow data comparison National standards eliminate needless duplication of effort to build transaction sets National standards allow the entire industry to operate more efficiently Can each state, along with the parties operating in that state, create a set of standards for that state? Yes, but the standards won�t be a national set of standards. That�s a big reason why the business processes and operations of multi-state players are so bogged down; a different system almost has to be built for each state. National standards, especially if they allow flexibility for the individual needs of individual states, are much more logical.Can each state, along with the parties operating in that state, create a set of standards for that state? Yes, but the standards won�t be a national set of standards. That�s a big reason why the business processes and operations of multi-state players are so bogged down; a different system almost has to be built for each state. National standards, especially if they allow flexibility for the individual needs of individual states, are much more logical.

45. OPTIONS Formats: Flat File or ANSI Build your own Program - flat file 09234 938 730239 789 Use existing software - ANSI - 9234*938*730239*789 External Technology Solutions Buy off the shelf Hire a consultant Use a 3rd party collection agent Value added network or the Internet A flat file is basically a one-dimensional or two-dimensional array�a list or table of items�with no hierarchical structure. An ASCII (American Standard Code for Information Interchange) Flat File is a basic file with ASCII characters and consisting of records of a single type, in which there is no embedded structure information governing relationships between records. The American Standards National Institute (ANSI), Accredited Standards Committee (ASC), X12 is an organization that develops Electronic Data Interchange (EDI) communication standards. The �X� represents Communications and �X12� is thus the twelfth Communication Standards Committee under the Accredited Standards Committee. This body is also referred to as: ANSI X12 ASC X12 or just X12 Here you can see some of the differences in reporting the same data: Leading zeros or fillers in the flat file to create a spacing (positioning) of each piece of data that never varies from record to record, and the use of delimiters in ANSI to denote where one data element begins and ends. Another difference is that you can use existing software to build an ANSI solution or build your own flat file program. Other options for solutions outside your internal IT department are off the shelf programs, consultants, outsourcing the data collection or sending, and communications carriers.A flat file is basically a one-dimensional or two-dimensional array�a list or table of items�with no hierarchical structure. An ASCII (American Standard Code for Information Interchange) Flat File is a basic file with ASCII characters and consisting of records of a single type, in which there is no embedded structure information governing relationships between records. The American Standards National Institute (ANSI), Accredited Standards Committee (ASC), X12 is an organization that develops Electronic Data Interchange (EDI) communication standards. The �X� represents Communications and �X12� is thus the twelfth Communication Standards Committee under the Accredited Standards Committee. This body is also referred to as: ANSI X12 ASC X12 or just X12 Here you can see some of the differences in reporting the same data: Leading zeros or fillers in the flat file to create a spacing (positioning) of each piece of data that never varies from record to record, and the use of delimiters in ANSI to denote where one data element begins and ends. Another difference is that you can use existing software to build an ANSI solution or build your own flat file program. Other options for solutions outside your internal IT department are off the shelf programs, consultants, outsourcing the data collection or sending, and communications carriers.

46. This diagram shows how the different components of EDI and options fit together to move the data from the sender to receiver and back. We start on the right with the sender. The sender has data residing in a database, and uses either a program from a vendor or one the sender has developed itself to map data from its location in the database to the proper location in the file being sent. The file is translated from the sender�s format to another if necessary and then sent using telecommunications software. The file passes through a network, typically either a Value Added Network (VAN) or the Internet. On the other end, the state uses a similar process in reverse to receive, translate if necessary, and map data to the proper location in the state�s database.This diagram shows how the different components of EDI and options fit together to move the data from the sender to receiver and back. We start on the right with the sender. The sender has data residing in a database, and uses either a program from a vendor or one the sender has developed itself to map data from its location in the database to the proper location in the file being sent. The file is translated from the sender�s format to another if necessary and then sent using telecommunications software. The file passes through a network, typically either a Value Added Network (VAN) or the Internet. On the other end, the state uses a similar process in reverse to receive, translate if necessary, and map data to the proper location in the state�s database.

47. SOFTWARE EDI Translation Software Converts application data into a standard EDI format Converts ANSI format to flat file Telecommunication Software Initiates communication session Establishes protocol Validates security Transmits the EDI data On an earlier slide you saw that one of the key components to EDI is hardware/software. There are almost as many hardware solutions as there are senders and receivers so we will not cover that part of the solution here. In the diagram on the slide just before this one, you saw that both the sender and receiver can have their own database programs that warehouse the data. On the sender�s end the EDI mapping / translation software will convert that data into a standard EDI format, and convert a flat file to ANSI file format or vice versa. Similar software on the receiver�s end converts an ANSI file to flat file format or vice versa, and maps the data in the file received to the appropriate locations in the receiver�s database. Communications software provides the link from the sender to the receiver, whether direct one-to-one, or via third-party networks, and provides the security needed to transmit the data safely and confidentially.On an earlier slide you saw that one of the key components to EDI is hardware/software. There are almost as many hardware solutions as there are senders and receivers so we will not cover that part of the solution here. In the diagram on the slide just before this one, you saw that both the sender and receiver can have their own database programs that warehouse the data. On the sender�s end the EDI mapping / translation software will convert that data into a standard EDI format, and convert a flat file to ANSI file format or vice versa. Similar software on the receiver�s end converts an ANSI file to flat file format or vice versa, and maps the data in the file received to the appropriate locations in the receiver�s database. Communications software provides the link from the sender to the receiver, whether direct one-to-one, or via third-party networks, and provides the security needed to transmit the data safely and confidentially.

48. COMMUNICATIONS Once the transmission is initiated, there are various ways to carry that transmission to its intended recipient. The primary ones used in EDI are: Value-Added Networks, which are companies that are similar to long-distance phone companies. Private networks established by the senders for their own use or by multiple partners. The Internet, primarily through a file transmission or sharing protocol known as FTP or encrypted FTP.Once the transmission is initiated, there are various ways to carry that transmission to its intended recipient. The primary ones used in EDI are: Value-Added Networks, which are companies that are similar to long-distance phone companies. Private networks established by the senders for their own use or by multiple partners. The Internet, primarily through a file transmission or sharing protocol known as FTP or encrypted FTP.

49. COURAGE I mentioned before that going to EDI takes courage�a lot of courage. We all know how difficult it can be to change. Change can be stressful because it brings risk, uncertainty, the unknown. That�s why change requires courage. I said before that successful EDI requires 99% courage and 1% preparation and some of you scoffed? EDI provides the opportunity to probe your entire operation�that can bring about a BIG CHANGE. EDI requires cooperation among players that by the nature of the beast tend to be adversarial�that can bring about a BIG CHANGE. Yes, EDI requires 99% courage but it can and has been done so you will have company.I mentioned before that going to EDI takes courage�a lot of courage. We all know how difficult it can be to change. Change can be stressful because it brings risk, uncertainty, the unknown. That�s why change requires courage. I said before that successful EDI requires 99% courage and 1% preparation and some of you scoffed? EDI provides the opportunity to probe your entire operation�that can bring about a BIG CHANGE. EDI requires cooperation among players that by the nature of the beast tend to be adversarial�that can bring about a BIG CHANGE. Yes, EDI requires 99% courage but it can and has been done so you will have company.

50. IAIABC Standards in Use Claims Release 1 Release 2 (No longer supported) Release 3/Combined Claims Product (CCP) Proof of Coverage Release 1 Release 2 Medical/Bill Payment Records Partially tested by Kentucky and in production Remainder has not been beta tested yet These are the IAIABC standards currently in use or in development. Claims Release 1 is what we will be using. Iowa has indicated that they will move to Release 3 when planned beta testing elsewhere is successfully completed. Release 3 has just been approved by the IAIABC�s EDI Council for beta testing; California and Zenith Insurance are currently planning to conduct that beta test. Proof of Coverage is used by several states to supplement or replace the information maintained by NCCI. Kansas considered starting out with this as a simpler product but the legislature set our priorities for us by requiring us to go with Claims Release 1.These are the IAIABC standards currently in use or in development. Claims Release 1 is what we will be using. Iowa has indicated that they will move to Release 3 when planned beta testing elsewhere is successfully completed. Release 3 has just been approved by the IAIABC�s EDI Council for beta testing; California and Zenith Insurance are currently planning to conduct that beta test. Proof of Coverage is used by several states to supplement or replace the information maintained by NCCI. Kansas considered starting out with this as a simpler product but the legislature set our priorities for us by requiring us to go with Claims Release 1.

51. EDI TRANSACTIONS There are two types of Claims records, shown here with their common names and ANSI designations. There are two types of Proof of Coverage Records, but there are no ANSI formats available. There is one type of Medical record, and the only approved format to date is ANSI.There are two types of Claims records, shown here with their common names and ANSI designations. There are two types of Proof of Coverage Records, but there are no ANSI formats available. There is one type of Medical record, and the only approved format to date is ANSI.

52. There are several steps involved in the successful transmission of an EDI record. Submitting or sending a report Identification by the receiver of the type of report Translation of the file into a format usable by the receiver Application of technical and business edits to each report in the file to ensure the data conforms to standards Accepting a report because it did not fail certain edits, or rejecting the report because it did fail one or more of those �fatal� edits Transmission of a acknowledgment back to the sender by the receiver that the report was received and that it passed all edits, or passed but failed non-critical edits, or failed a critical (fatal) edit.There are several steps involved in the successful transmission of an EDI record. Submitting or sending a report Identification by the receiver of the type of report Translation of the file into a format usable by the receiver Application of technical and business edits to each report in the file to ensure the data conforms to standards Accepting a report because it did not fail certain edits, or rejecting the report because it did fail one or more of those �fatal� edits Transmission of a acknowledgment back to the sender by the receiver that the report was received and that it passed all edits, or passed but failed non-critical edits, or failed a critical (fatal) edit.

53. EDI TRANSMISSION COMPONENTS A single transmission contains one or more batches of records. Each batch contains: A header which describes what is in the batch One or more transactions containing one or more records (reports) A trailer which signifies that the batch is complete at that point and provides a confirming record count. We will go into much more detail about this in Sharon�s presentation this afternoon.A single transmission contains one or more batches of records. Each batch contains: A header which describes what is in the batch One or more transactions containing one or more records (reports) A trailer which signifies that the batch is complete at that point and provides a confirming record count. We will go into much more detail about this in Sharon�s presentation this afternoon.

54. AN EDI TRANSMISION This diagram graphically shows the composition of a transmission. A transmission is composed of one or more batches. Each batch is composed of a header record, one or more transactions, and a trailer record.This diagram graphically shows the composition of a transmission. A transmission is composed of one or more batches. Each batch is composed of a header record, one or more transactions, and a trailer record.

55. EDI BATCH COMPONENTS This shows the composition of a single batch. Note that claims, POC, and medical data are not mixed in a single batch.This shows the composition of a single batch. Note that claims, POC, and medical data are not mixed in a single batch.

56. EDI HEADER These are the main components of a header record. Each of these is a data element which gives us information about the transmission: Who sent it? Who is supposed to get it? What does it contain? When was it sent?These are the main components of a header record. Each of these is a data element which gives us information about the transmission: Who sent it? Who is supposed to get it? What does it contain? When was it sent?

57. EDI TRAILER These are the main components of a trailer record. Each of these is a data element which gives us information about the transmission: What did it contain? How many records were sent (excluding the header and trailer)?These are the main components of a trailer record. Each of these is a data element which gives us information about the transmission: What did it contain? How many records were sent (excluding the header and trailer)?

58. EDI Acknowledgement These are the main components of an acknowledgment record. Identification data used to match the acknowledgment from the receiver to the record from the sender. A code indicating whether the record being acknowledged was accepted (passed all edits), accepted with errors, or failed and was rejected. How many errors did the record contain according to the edits? For each error, where was the error, what was the error, and if the error was contained in what we call a variable segment, which segment? Variable segments are sets of data elements that go together, such as a benefit type code and a benefit amount. If the report contains paid to date benefits, there could have been more than one type of benefit paid (for example, temporary total, temporary partial, and permanent partial. There would be a code for each of these benefit types and a corresponding amount for each benefit type. In the example I just gave, there would be three variable segments: TT code and an amount TP code and an amount PP code and an amount.These are the main components of an acknowledgment record. Identification data used to match the acknowledgment from the receiver to the record from the sender. A code indicating whether the record being acknowledged was accepted (passed all edits), accepted with errors, or failed and was rejected. How many errors did the record contain according to the edits? For each error, where was the error, what was the error, and if the error was contained in what we call a variable segment, which segment? Variable segments are sets of data elements that go together, such as a benefit type code and a benefit amount. If the report contains paid to date benefits, there could have been more than one type of benefit paid (for example, temporary total, temporary partial, and permanent partial. There would be a code for each of these benefit types and a corresponding amount for each benefit type. In the example I just gave, there would be three variable segments: TT code and an amount TP code and an amount PP code and an amount.

59. KANSAS EDI TRANSACTIONS I told you I would give you an overview about how EDI is going to work in Kansas. Kansas will be accepting First and Subsequent Reports of Injury from carriers, self-insured employers, self-insured group pools, and third party administrators. In return, Kansas will acknowledge receipt of those transactions and notify the sender whether the records are: Error free (according to the edits used)�but there may be errors that the edits cannot catch Acceptable but contain non-fatal errors that should be corrected with a correction report, or Not acceptable due to failure to meet one or more fatal edits and the report must be replaced.I told you I would give you an overview about how EDI is going to work in Kansas. Kansas will be accepting First and Subsequent Reports of Injury from carriers, self-insured employers, self-insured group pools, and third party administrators. In return, Kansas will acknowledge receipt of those transactions and notify the sender whether the records are: Error free (according to the edits used)�but there may be errors that the edits cannot catch Acceptable but contain non-fatal errors that should be corrected with a correction report, or Not acceptable due to failure to meet one or more fatal edits and the report must be replaced.

60. This diagram shows how various documents are transmitted back and forth, and the relationship between the vendor and trading partners for testing and for maintenance of the trading partner relationship. (such as the trading partner documents in the upper left corner) Reporting entities will send files to Kansas either by means of a VAN or the Internet. A Value Added Network (VAN) is a facility used to exchange electronic files between organizations. A VAN can be viewed as a huge community �hard drive� that contains separate storage spaces (Mail Boxes) for its subscribers. There is a mailbox for the sender and a mailbox for the receiver. The sender may be reporting to many states. The VAN sorts the mail and distributes it to the appropriate receiver mailboxes. Our vendor, Bridium, will access our mailbox and download the files from it. After processing the reports through the edits, Bridium will return an acknowledgment to the sender via the VAN and send the accepted reports on to us. Bridium will maintain a Web site that certain trading partners who meet certain criteria (volume of reporting), for example, can use to manually key in the report data. The Web form will apply in real time most of the same edits used to process flat file and ANSI reports sent via VANs.This diagram shows how various documents are transmitted back and forth, and the relationship between the vendor and trading partners for testing and for maintenance of the trading partner relationship. (such as the trading partner documents in the upper left corner) Reporting entities will send files to Kansas either by means of a VAN or the Internet. A Value Added Network (VAN) is a facility used to exchange electronic files between organizations. A VAN can be viewed as a huge community �hard drive� that contains separate storage spaces (Mail Boxes) for its subscribers. There is a mailbox for the sender and a mailbox for the receiver. The sender may be reporting to many states. The VAN sorts the mail and distributes it to the appropriate receiver mailboxes. Our vendor, Bridium, will access our mailbox and download the files from it. After processing the reports through the edits, Bridium will return an acknowledgment to the sender via the VAN and send the accepted reports on to us. Bridium will maintain a Web site that certain trading partners who meet certain criteria (volume of reporting), for example, can use to manually key in the report data. The Web form will apply in real time most of the same edits used to process flat file and ANSI reports sent via VANs.






66. KANSASIMPLEMENTATION GUIDE Outlines the EDI requirements of the State of Kansas Provides contact information Documents testing requirements Contains required agreements and profiles to begin EDI processes Kansas has its own Implementation Guide; as I mentioned the IAIABC has a generic one. The Kansas Guide, when used in conjunction with the IAIABC Release 1 EDI Implementation Guide, provides the business and technical information to meet KDWC alternate reporting requirements (alternate to the hard copy K-WC 1101 A and the OCC) for: EDI submissions to KDWC The paper equivalents that may be submitted to KDWC or exchanged between insurers, employers, claim administrators, injured workers, and others entitled to this information (in other words, if someone needs a copy of an EDI report and is entitled to that information). Contact information for Kansas Workers Compensation staff and our partner Bridium, as well as a list of other experienced vendors providing EDI services is in the Guide and on the Web. KDWC EDI reports must be sent through an approved EDI data transport method or vendor described in the Test and Production Process portion of the Guide. Forms for documenting information about the trading partners and specific reporting requirements to be followed are in the Guide also.Kansas has its own Implementation Guide; as I mentioned the IAIABC has a generic one. The Kansas Guide, when used in conjunction with the IAIABC Release 1 EDI Implementation Guide, provides the business and technical information to meet KDWC alternate reporting requirements (alternate to the hard copy K-WC 1101 A and the OCC) for: EDI submissions to KDWC The paper equivalents that may be submitted to KDWC or exchanged between insurers, employers, claim administrators, injured workers, and others entitled to this information (in other words, if someone needs a copy of an EDI report and is entitled to that information). Contact information for Kansas Workers Compensation staff and our partner Bridium, as well as a list of other experienced vendors providing EDI services is in the Guide and on the Web. KDWC EDI reports must be sent through an approved EDI data transport method or vendor described in the Test and Production Process portion of the Guide. Forms for documenting information about the trading partners and specific reporting requirements to be followed are in the Guide also.

67. Simple Steps To Implementing EDI External Review: State Reporting Requirements Technologies & EDI options available Assess trading partner capabilities Internal review Data Collection Process Technologies & EDI options Evaluation Time Frame and resources Cost-benefit analysis of options & Change Change Adapt, acquire and/or outsource As a quick review, the simple steps to implement EDI in Kansas include: An external review of state reporting requirements and what technologies the state will allow An internal review of your own data collection processes and the technologies and options that fit your system An evaluation of whether you have the resources to gear up, how long it would take, and how much you stand to gain given the changes you will need to make Making the changes by adapting your existing system, acquiring an off-the-shelf solution, or outsourcing.As a quick review, the simple steps to implement EDI in Kansas include: An external review of state reporting requirements and what technologies the state will allow An internal review of your own data collection processes and the technologies and options that fit your system An evaluation of whether you have the resources to gear up, how long it would take, and how much you stand to gain given the changes you will need to make Making the changes by adapting your existing system, acquiring an off-the-shelf solution, or outsourcing.

68. EDI Web Sites

69. This series of slides contains the speakers notes and may be used after the Training Session as a refresher course.This series of slides contains the speakers notes and may be used after the Training Session as a refresher course.

70. IMPLEMENTATION REQUIREMENTS EDI Reports and Related Events Business & Technical Data Reporting Requirements This portion of the KDWC Training Session will provide you with the information necessary to understand and comply with Kansas�s EDI Reporting requirements. * The EDI reports and Related Events will provide you with both the Business and Technical data reporting process requirements. -------------------------------------------------------------------------------------------------------- * During these sessions we will build upon the previous sessions and clarify the EDI statute�s reporting requirements and enhance your knowledge of EDI. * We recognize that EDI and IAIABC Standards are new to many of you. As time permits we will point out other IG sections that will provide insight and help you plan to make your EDI Implementation with Kansas successful. We have been involved in the IAIABC EDI Committees and have sent out our requirements for initial review to claim administrators already sending EDI reports in multiple states and have tried to anticipate your questions, when we wrote the KDWC Implementation Guide. This portion of the KDWC Training Session will provide you with the information necessary to understand and comply with Kansas�s EDI Reporting requirements. * The EDI reports and Related Events will provide you with both the Business and Technical data reporting process requirements. -------------------------------------------------------------------------------------------------------- * During these sessions we will build upon the previous sessions and clarify the EDI statute�s reporting requirements and enhance your knowledge of EDI. * We recognize that EDI and IAIABC Standards are new to many of you. As time permits we will point out other IG sections that will provide insight and help you plan to make your EDI Implementation with Kansas successful. We have been involved in the IAIABC EDI Committees and have sent out our requirements for initial review to claim administrators already sending EDI reports in multiple states and have tried to anticipate your questions, when we wrote the KDWC Implementation Guide.

71. DATA REPORTING REQUIREMENTS Series of decision tables to express Kansas reporting requirements Business or Claim Events Data Element Requirements Data Quality Edits The objective of the IAIABC Reporting Standards was to develop a common State WC Reporting process. It sought to normalize the data requirements, and standardize reporting formats and submission requirements. We use �Decision Tables� to express any IAIABC EDI state�s reporting requirements. We will discuss each of the following: Business Events: When is a Report (MTC) required and when is it due. Explain: Maintenance Type Code: Business Event, Denial, Cancel, etc. Data Requirements: Data Mandatory, Conditional Optional by MTC Edit/Error Matrix: What Edits are applied to the data elements Acknowledgements: A response to your Report which informs you if the Report was accepted and if applicable what errors were noted. Error Corrections: The process of correcting report errors. The objective of the IAIABC Reporting Standards was to develop a common State WC Reporting process. It sought to normalize the data requirements, and standardize reporting formats and submission requirements. We use �Decision Tables� to express any IAIABC EDI state�s reporting requirements. We will discuss each of the following: Business Events: When is a Report (MTC) required and when is it due. Explain: Maintenance Type Code: Business Event, Denial, Cancel, etc. Data Requirements: Data Mandatory, Conditional Optional by MTC Edit/Error Matrix: What Edits are applied to the data elements Acknowledgements: A response to your Report which informs you if the Report was accepted and if applicable what errors were noted. Error Corrections: The process of correcting report errors.

72. TYPES OF EDI REPORTS MTC - Maintenance Type Code Transaction Types Business or Claim Event Reports 148 - FROI - First Report of Injury A49 - SROI - Subsequent Report of Injury EDI Receipt AK1 - Acknowledgement from the Jurisdiction Kansas is essentially adding an alternative for insurers to meet its data Reporting Requirements. In an EDI environment we ask for two basic reports: A FROI First Report of Injury, and a SROI Subsequent Report of Injury. * A FROI is the typical Report of Accident * A SROI the report of a claim processing activity such as an Initial Payment, Final, and/ or a Periodic summary of benefit paid to date. * Two Formats with different MTC to denote the business event. The FROI Format allows you to Report a new Claim (00-Original, or Report that you denied a New Claim. MTC (04) The SROI allows you to send an Initial Payments (or equivalents) on a Claim, the closing of a Claim (Final) or Submit a Periodic Report: Annual Report MTC (AN) The FROI and SROI Format also allows you to Change Data you submitted, or Correct Reporting errors. We will discuss these later. MTC (02) (CO) ---------------------------------------------------------------------------------------------- In the event that, you acquire a claim, (Insolvency or Purchase) a FROI MTC (AU) is used. If the claim is filed in the wrong jurisdiction, or the jurisdiction changes, a Cancel MTC (01) is used Kansas is essentially adding an alternative for insurers to meet its data Reporting Requirements. In an EDI environment we ask for two basic reports: A FROI First Report of Injury, and a SROI Subsequent Report of Injury. * A FROI is the typical Report of Accident * A SROI the report of a claim processing activity such as an Initial Payment, Final, and/ or a Periodic summary of benefit paid to date. * Two Formats with different MTC to denote the business event. The FROI Format allows you to Report a new Claim (00-Original, or Report that you denied a New Claim. MTC (04) The SROI allows you to send an Initial Payments (or equivalents) on a Claim, the closing of a Claim (Final) or Submit a Periodic Report: Annual Report MTC (AN) The FROI and SROI Format also allows you to Change Data you submitted, or Correct Reporting errors. We will discuss these later. MTC (02) (CO) ---------------------------------------------------------------------------------------------- In the event that, you acquire a claim, (Insolvency or Purchase) a FROI MTC (AU) is used. If the claim is filed in the wrong jurisdiction, or the jurisdiction changes, a Cancel MTC (01) is used

73. 46 ACKNOWLEDGEMENTS transactions sent back to trading partner from the jurisdiction to let you know you file was received and what their status is! Transaction Accepted (TA) Complete, no further action required Transaction Accepted with Errors (TE) Correct errors identified with CO report Transaction Rejected (TR) Correct & Resubmit entire report The Kansas EDI System will review each report that you submit applying the MCO and Edits we just reviewed and send you an acknowledgement: (Remember the Transaction Sequence for Corrections and Changes.) To confirm they received your report. State if the Report was Accepted (TA), Accepted w/errors (TE), or Rejected (TR). If you receive a TA, no further action is required of that Report. If you receive a TE, it will identify the DNs in Error and the associated Edits. You must submit a Correction Report. If you receive a TR, you must correct the problem and resubmit the report. The Kansas EDI System will review each report that you submit applying the MCO and Edits we just reviewed and send you an acknowledgement: (Remember the Transaction Sequence for Corrections and Changes.) To confirm they received your report. State if the Report was Accepted (TA), Accepted w/errors (TE), or Rejected (TR). If you receive a TA, no further action is required of that Report. If you receive a TE, it will identify the DNs in Error and the associated Edits. You must submit a Correction Report. If you receive a TR, you must correct the problem and resubmit the report.

74. 46 REPORT SEQUENCE REQUIREMENTS See: Acknowledgements, Corrections & Change Report Sequencing, Pg 46. The Previous Slides illustrated the order in which a Claim Administrator submits claim Event information. This slide will address the sequence of Change and Correction Reports. Each Report that is sent will be edited for data quality and proper sequence. KDWC will acknowledge each Report. When that Acknowledgement indicates that the Report was rejected (TR), you must correct and resubmit the report. (MTC = Rejected Report�s MTC) When the Acknowledgement indicates that the Report contained data errors (TE), you must submit the corrected data elements. (MTC = CO) When you change data identified in the KDWC IG for the Change MTC, you must report the changed data. (MTC = 02)See: Acknowledgements, Corrections & Change Report Sequencing, Pg 46. The Previous Slides illustrated the order in which a Claim Administrator submits claim Event information. This slide will address the sequence of Change and Correction Reports. Each Report that is sent will be edited for data quality and proper sequence. KDWC will acknowledge each Report. When that Acknowledgement indicates that the Report was rejected (TR), you must correct and resubmit the report. (MTC = Rejected Report�s MTC) When the Acknowledgement indicates that the Report contained data errors (TE), you must submit the corrected data elements. (MTC = CO) When you change data identified in the KDWC IG for the Change MTC, you must report the changed data. (MTC = 02)

75. 48 FROI & SROI BUSINESS (CLAIM) EVENTS See Page 48 in the KS Implementation GuideSee Page 48 in the KS Implementation Guide

76. FROI & SROI BUSINESS (CLAIM) EVENTS

77. 40 Narrative, 42 CE Table FROI BUSINESS (CLAIM) EVENTS FROI= First Report of Injury Original: 28 days from employer notification Denial: Same as Original and as occurs, 5 days Cancel: Upon improper filing, 5 days Acquired: 21 days after acquiring claim Change: As occurs, 5 days Correct: 5 days after TE Acknowledgement See KDWC IG: KDWC FROI & SROI Event Tables & Narrative Pgs. 40-42 An Original: The FROI contains the following data to monitor timely submission: Date of Injury Date Reported to Employer Date Reported to Claim Administrator A FROI Denial: A FROI Denial may be submitted in place of the Original, or after the Original and before Benefit payments have begun. A Cancel: Is submitted when a report is sent in error or the jurisdiction changes. A FROI Change is submitted when ever FROI data changes. A FROI Correction is submitted when ever corrections to a FROI transaction are made. See KDWC IG: KDWC FROI & SROI Event Tables & Narrative Pgs. 40-42 An Original: The FROI contains the following data to monitor timely submission: Date of Injury Date Reported to Employer Date Reported to Claim Administrator A FROI Denial: A FROI Denial may be submitted in place of the Original, or after the Original and before Benefit payments have begun. A Cancel: Is submitted when a report is sent in error or the jurisdiction changes. A FROI Change is submitted when ever FROI data changes. A FROI Correction is submitted when ever corrections to a FROI transaction are made.

78. 40 Narrative, 42 CE table SROI BUSINESS (CLAIM) EVENTS SROI= Subsequent Report of Injury Initial Payment: 5 days following initial payment of indemnity IP Equivalents: Acquired Payment: 5 days following initial payment of indemnity by acquiring CA Full Salary: 5 days following initial payment of salary in lieu of compensation Compensable Death: 5 days following CA�s knowledge of death of injured worker See KDWC IG: KDWC FROI & SROI Event Tables Pg. 40-42 See KDWC IG: KDWC FROI & SROI Event Tables Pg. 40-42

79. 40 Narrative, 42 CE Table SROI BUSINESS (CLAIM) EVENTS Denial: as occurs, 5 days Final: claim closes, 5 days after CA determines no future indemnity to be paid Annual: within 10 days of June 1 Change: As occurs, 5 days Correct: 5 days after TE Acknowledgement Upon Request: specific request for claim information See KDWC IG: KDWC FROI & SROI Event Tables Pg. 40-42 See KDWC IG: KDWC FROI & SROI Event Tables Pg. 40-42

80. REPORT SEQUENCE REQUIREMENTS BASIC SEQUENCING RULES Must send and have an acknowledgement of TA or TE before sending the next report in the sequence Must correct errors (TE) with a Correction (CO) MTC You must send something, before you can change it with Change (02) MTC

81. 43 REPORT SEQUENCE REQUIREMENTS See Transaction Sequence Requirements Pg. 43 The Previous slide illustrated the basic two Reports and variations of these reports to resolve data errors or for specific claim handling situations. As in any business relationship, transactions occur in a set sequence. The most common type of Report sequencing is simply filing an Original report and no compensable indemnity or medical is paid and so the process would stop right there for that claim.See Transaction Sequence Requirements Pg. 43 The Previous slide illustrated the basic two Reports and variations of these reports to resolve data errors or for specific claim handling situations. As in any business relationship, transactions occur in a set sequence. The most common type of Report sequencing is simply filing an Original report and no compensable indemnity or medical is paid and so the process would stop right there for that claim.

82. 43 REPORT SEQUENCE REQUIREMENTS See Typical EDI Report Sequencing Pg.43 In Kansas the typical EDI Report sequencing on paid claims will follow one of two general paths: Begin: Original * If Original may follow with the Initial Payment or Equivalent, and once the claim closes a Final with an Annual report on June 1 of the following calendar year if recoveries are made or additional payments recorded after the final and the claim remains closed. Or May follow with a Annual to report total medical paid to date if no indemnity was paid. That is the typical report sequencing, now lets muddy the water a bit. See Typical EDI Report Sequencing Pg.43 In Kansas the typical EDI Report sequencing on paid claims will follow one of two general paths: Begin: Original * If Original may follow with the Initial Payment or Equivalent, and once the claim closes a Final with an Annual report on June 1 of the following calendar year if recoveries are made or additional payments recorded after the final and the claim remains closed. Or May follow with a Annual to report total medical paid to date if no indemnity was paid. That is the typical report sequencing, now lets muddy the water a bit.

83. 44 REPORT SEQUENCE REQUIREMENTS See Alternate EDI Report Sequencing Pg. 44 The Previous slides illustrated the basic two Reports and variations of these reports to resolve data errors or for specific claim handling situations. For example, you register a claim to validate coverage to assign/investigate the claim to determine compensability, etc. IAIABC MTCs mirror Claim Processing Events: Begin: Original or Denial * If Original may follow with a Cancel it if filed in error or jurisdiction incorrect (Before a Denial, payments, etc.) You may also File a Denial and Stop (if no payments made) after you have filed an Original and EDI reporting on that claim would stop. If it is a compensable claim may encounter the typical report sequencing we just discussed. If a claim is denied after indemnity benefits commenced, submit the Denial Report (04) and EDI reporting stops for that claim. * If You Acquired the Claim, your options are the same as filing an Original. You can cancel only if no payments or Denial has been made, etc.See Alternate EDI Report Sequencing Pg. 44 The Previous slides illustrated the basic two Reports and variations of these reports to resolve data errors or for specific claim handling situations. For example, you register a claim to validate coverage to assign/investigate the claim to determine compensability, etc. IAIABC MTCs mirror Claim Processing Events: Begin: Original or Denial * If Original may follow with a Cancel it if filed in error or jurisdiction incorrect (Before a Denial, payments, etc.) You may also File a Denial and Stop (if no payments made) after you have filed an Original and EDI reporting on that claim would stop. If it is a compensable claim may encounter the typical report sequencing we just discussed. If a claim is denied after indemnity benefits commenced, submit the Denial Report (04) and EDI reporting stops for that claim. * If You Acquired the Claim, your options are the same as filing an Original. You can cancel only if no payments or Denial has been made, etc.

84. 47 REPORT SEQUENCE REQUIREMENTS See OCC Reporting Using IAIABC Standards Report Sequencing Pg. 47 The first year an OCC survey sample claim administrator participates in EDI program may require an additional reporting requirement if they so choose �Reach back� option since no EDI FROI sent (EDI is forward going) Will send 200 or less claims that closed in previous calendar year (legacy claims) randomly selected An corresponding annuals In the same batch (sequencing issues) Only the 00 and AN are required on first year OCC claims filed using IAIABC EDI standards See OCC Reporting Using IAIABC Standards Report Sequencing Pg. 47 The first year an OCC survey sample claim administrator participates in EDI program may require an additional reporting requirement if they so choose �Reach back� option since no EDI FROI sent (EDI is forward going) Will send 200 or less claims that closed in previous calendar year (legacy claims) randomly selected An corresponding annuals In the same batch (sequencing issues) Only the 00 and AN are required on first year OCC claims filed using IAIABC EDI standards

85. (1) 26-28,27-32 (2)33,34-37 (3)58,59 (4)56-58,60-1 (5)51,52 (6)117-129 DATA ELEMENTREQUIREMENTS KDWC/IAIABC Crosswalk Tables Kansas 1101-A Paper form w/IAIABC DN Refs. & OCC Record layout IAIABC Forms w/IAIABC DN References IAIABC Flat File Data Element Lists FROI/SROI Requirements Table FROI/SROI Scenarios in IAIABC Format Kansas EDI Requirements are based on IAIABC Standards. Go to the IG Information and Help section to obtain an IAIABC Release 1 Implementation Guide. Pg.21 The Kansas Implementation Guide provides Data Element Requirements in SIX formats to provide a solid understanding of the KDWC EDI Reporting Data Requirements. In the Reports and Data requirements Section: 1. Data crosswalks between Kansas 1101-A & OCC and IAIABC Data Elements. 1101-a requirements: Pgs. 26-28 OCC requirements Pgs. 29-32 2. Previous Kansas 1101-a Form with IAIABC DN references in bold black font to relate current requirements to the new requirements. Pg. 33 The flat file record layout of the current OCC study requirements: Pgs. 34-37 3. IAIABC Forms with IAIABC DN references in red font to relate DN Number to Usage example. FROI : IAIABC IA-1 and IA-1 OSHA Pgs. 58 & 59 IAIABC Date Elements in Flat File sequence as a �laundry list� of FROI and SROI Formats and example of how to package the data. FMT = Data Format: Length and Type Date(CCYYMMDD), A/N Alpha Numeric, N = math value Beg/End = File data begin/End positions. FROI: Pgs. 56-58 SROI: Pgs. 60 & 61 In the EDI Reports and Related Events Section: 5. FROI and SROI Data Requirements show data mandatory, conditional, Optional (M/C/O) requirements by Report Type (MTC) FROI: Pg. 51 SROI Pg 52 In the Appendix: 6. A Business Scenario and complete IAIABC format (record layout) for selected FROI & SROI business events. Pg 117-129. Kansas EDI Requirements are based on IAIABC Standards. Go to the IG Information and Help section to obtain an IAIABC Release 1 Implementation Guide. Pg.21 The Kansas Implementation Guide provides Data Element Requirements in SIX formats to provide a solid understanding of the KDWC EDI Reporting Data Requirements. In the Reports and Data requirements Section: 1. Data crosswalks between Kansas 1101-A & OCC and IAIABC Data Elements. 1101-a requirements: Pgs. 26-28 OCC requirements Pgs. 29-32 2. Previous Kansas 1101-a Form with IAIABC DN references in bold black font to relate current requirements to the new requirements. Pg. 33 The flat file record layout of the current OCC study requirements: Pgs. 34-37 3. IAIABC Forms with IAIABC DN references in red font to relate DN Number to Usage example. FROI : IAIABC IA-1 and IA-1 OSHA Pgs. 58 & 59 IAIABC Date Elements in Flat File sequence as a �laundry list� of FROI and SROI Formats and example of how to package the data. FMT = Data Format: Length and Type Date(CCYYMMDD), A/N Alpha Numeric, N = math value Beg/End = File data begin/End positions. FROI: Pgs. 56-58 SROI: Pgs. 60 & 61 In the EDI Reports and Related Events Section: 5. FROI and SROI Data Requirements show data mandatory, conditional, Optional (M/C/O) requirements by Report Type (MTC) FROI: Pg. 51 SROI Pg 52 In the Appendix: 6. A Business Scenario and complete IAIABC format (record layout) for selected FROI & SROI business events. Pg 117-129.

86. 51 & 52 FROI/SROIREQUIREMENT TABLES An Element Requirement Table will tell you exactly what elements are: �M�andatory �C�onditional �O�ptional for EACH Report that is required by the State Data Element Number & Name Purpose(s) of Collecting the Data Element By Maintenance Type Code (MTC) Mandatory, Conditional, and Optional designation See Page Pgs. 51 FROI 52 SROI Object: Understand how to read the FROI & SROI Requirements Tables: DN = IAIABC Data Number Date Name = IAIABC Data Name DN Used to: briefly describes the purpose of requiring the data element; edi processing requirement, match claim, ID, contact, statistical element MTC = Maintenance Type Codes - Equate to Legend 00 = Original, etc. MCO = Each data element identified by MTC as Mandatory, Conditional, Optional. See Page Pgs. 51 FROI 52 SROI Object: Understand how to read the FROI & SROI Requirements Tables: DN = IAIABC Data Number Date Name = IAIABC Data Name DN Used to: briefly describes the purpose of requiring the data element; edi processing requirement, match claim, ID, contact, statistical element MTC = Maintenance Type Codes - Equate to Legend 00 = Original, etc. MCO = Each data element identified by MTC as Mandatory, Conditional, Optional.

87. 52 SROIVARIABLE SEGMENTS Variable Segment Counters How many sets of what kind of data is being provided Number of Permanent Impairments Number of Payment/Adjustments Number of Paid to date, Reduced Earnings, Recoveries The IAIABC Standards were designed to meet State Requirements and take into account the Claim Administrator claim handling processes. Many of these processes produce one or more sets of similar data. For Example: A claim may involve several witnesses, or several medical bills. The IAIABC Claim Subsequent Report provides five types of similar repeating data. One aspect of the report format is to provide purely technical data: How many sets of what kind of data is being provided. (Variable Segment Counters) The third set of repeating data is can be confusing: The Technical aspect is that two data elements (flat file fields) a Code and an Amount are used to pass three different sets of data: Paid To Date, Reduced Earning, and Recoveries. (up to 25 occurrences allowed all three) These are three separate business Processes. Paid To Date: An IAIABC Codes for DCI type data and the associated Amount. Ex: Funeral Expenses Paid to Date/ Total Medical Reduced Earnings: An IAIABC Code and associated amount Identified as a week of actual or deemed reduced earnings. Recovery: An IAIABC Code and associated amount identified as a specific recovery on the claim: Example: Special Fund (WC fund- insolvency)/ Subrogation, etc. See the IAIABC Release 1 Specifications for definition and code values. The IAIABC Standards were designed to meet State Requirements and take into account the Claim Administrator claim handling processes. Many of these processes produce one or more sets of similar data. For Example: A claim may involve several witnesses, or several medical bills. The IAIABC Claim Subsequent Report provides five types of similar repeating data. One aspect of the report format is to provide purely technical data: How many sets of what kind of data is being provided. (Variable Segment Counters) The third set of repeating data is can be confusing: The Technical aspect is that two data elements (flat file fields) a Code and an Amount are used to pass three different sets of data: Paid To Date, Reduced Earning, and Recoveries. (up to 25 occurrences allowed all three) These are three separate business Processes. Paid To Date: An IAIABC Codes for DCI type data and the associated Amount. Ex: Funeral Expenses Paid to Date/ Total Medical Reduced Earnings: An IAIABC Code and associated amount Identified as a week of actual or deemed reduced earnings. Recovery: An IAIABC Code and associated amount identified as a specific recovery on the claim: Example: Special Fund (WC fund- insolvency)/ Subrogation, etc. See the IAIABC Release 1 Specifications for definition and code values.

88. 52 SROIVARIABLE SEGMENTS Permanent Impairment Body part code & % Impairment Max # of occurences per record: 6 Payment/Adjustment Code, PTD & Weekly Amount Max # of occurences per record: 10 Paid To Date/Reduced Earn/Recov Code & Amount Max # of occurences per record: 25 Many of these processes produce one or more sets of similar data. For Example: A claim may involve several witnesses, or several medical bills. The IAIABC Claim Subsequent Report provides five types of similar repeating data. The Business aspect of this is as follows: See Pg 60 in KS Guide SROI Flat File Record & IA R1 Guide in flat file format section Pgs. 4.15-4.16 * Permanent Impairment Body Part Code and % Impairment (up to 6 times) * Payment/Adjustments: (up to ten times) 85 - Code (What benefit is being paid? TTD) 86 - Total (How Much paid to Date) 87 - Weekly Amount 88 - Start Date 89 - End Date 90 - Weeks Paid 91 - Days paid The third set of repeating data is can be confusing: The Technical aspect is that two data elements (flat file fields) a Code and an Amount are used to pass three different sets of data: Paid To Date, Reduced Earning, and Recoveries. (up to 25 occurrences allowed all three) These are three separate business Processes. Paid To Date: An IAIABC Codes for DCI type data and the associated Amount. Ex: Funeral Expenses Paid to Date/ Total Medical Reduced Earnings: An IAIABC Code and associated amount Identified as a week of actual or deemed reduced earnings. Recovery: An IAIABC Code and associated amount identified as a specific recovery on the claim: Example: Special Fund (WC fund- insolvency)/ Subrogation, etc. See the IAIABC Release 1 Specifications for definition and code values. Many of these processes produce one or more sets of similar data. For Example: A claim may involve several witnesses, or several medical bills. The IAIABC Claim Subsequent Report provides five types of similar repeating data. The Business aspect of this is as follows: See Pg 60 in KS Guide SROI Flat File Record & IA R1 Guide in flat file format section Pgs. 4.15-4.16 * Permanent Impairment Body Part Code and % Impairment (up to 6 times) * Payment/Adjustments: (up to ten times) 85 - Code (What benefit is being paid? TTD) 86 - Total (How Much paid to Date) 87 - Weekly Amount 88 - Start Date 89 - End Date 90 - Weeks Paid 91 - Days paid The third set of repeating data is can be confusing: The Technical aspect is that two data elements (flat file fields) a Code and an Amount are used to pass three different sets of data: Paid To Date, Reduced Earning, and Recoveries. (up to 25 occurrences allowed all three) These are three separate business Processes. Paid To Date: An IAIABC Codes for DCI type data and the associated Amount. Ex: Funeral Expenses Paid to Date/ Total Medical Reduced Earnings: An IAIABC Code and associated amount Identified as a week of actual or deemed reduced earnings. Recovery: An IAIABC Code and associated amount identified as a specific recovery on the claim: Example: Special Fund (WC fund- insolvency)/ Subrogation, etc. See the IAIABC Release 1 Specifications for definition and code values.

89. F-67-70, S-69-74, H-73-74 DATA QUALITY EDITS All Reports submitted to KDWC are edited against the appropriate edit tables There are several types of edits data presence data relationships data values report sequence matching a report to a claim All Reports submitted to KDWC are edited against the appropriate edit tables. There are several types of edits; Data presence, data relationships, data values, report sequence, and matching a report to a claim. Each edit table indicates what edits apply to each data element for a given report. See FROI: Pg. 67-70 SROI: Pg. 69-74 HD1 & TR1: 73-74 All Reports submitted to KDWC are edited against the appropriate edit tables. There are several types of edits; Data presence, data relationships, data values, report sequence, and matching a report to a claim. Each edit table indicates what edits apply to each data element for a given report. See FROI: Pg. 67-70 SROI: Pg. 69-74 HD1 & TR1: 73-74

90. F-67-70, S-69-74, H-73-74 DATA QUALITY EDITS Each edit table indicates what edits apply to each data element for a given report Identifies the Error #, DN # and possibly text description of error that is returned by the State in Acknowledgement record This information found in Edit decision tables or edit matrices FROI SROI Header & Trailer

91. 64 & 65 DATA QUALITY EDITS Report Level Edits Examples Edit 039 no match on Database Edit 057 Duplicate transmission Edit 053 No Matching First Report Edit 063 Invalid Event Sequence REPORT LEVEL EDITS: Edits such as matching a report to a claim or report submission sequence errors produce report level errors that usually result in rejecting the entire report. Example: Edit 039 no match on Database Edit 057 Duplicate transmission Edit 053 No Matching First Report Edit 063 Invalid Event Sequence REPORT LEVEL EDITS: Edits such as matching a report to a claim or report submission sequence errors produce report level errors that usually result in rejecting the entire report. Example: Edit 039 no match on Database Edit 057 Duplicate transmission Edit 053 No Matching First Report Edit 063 Invalid Event Sequence

92. 78 & 79 MATCH ROUTINES See page 78 & 79See page 78 & 79

93. 65 TRANSACTION SEQUENCE REQUIREMENTS (Edit 063) See page 65See page 65

94. 75 DATA QUALITY EDITS Conditional Edits Edit Matrix Tables Comments Examples DN25 Industry Code and Edit 58 Code/ID invalid DN02 Maintenance Type Code and edit 42 Statutory invalid CONDITIONAL EDITS: on occasion, an edit is applied conditionally or additional information is required to perform the edit. For example, DN 25 Industry Code- EDIT 058 CODE/ID Invalid is edited against SIC/NAICs tables and report type (MTC) is edited for MTCs accepted by KDWC (EDIT 042 Not statutorily valid). These comments for FROI & SROI on pg. 72 of KS IG. CONDITIONAL EDITS: on occasion, an edit is applied conditionally or additional information is required to perform the edit. For example, DN 25 Industry Code- EDIT 058 CODE/ID Invalid is edited against SIC/NAICs tables and report type (MTC) is edited for MTCs accepted by KDWC (EDIT 042 Not statutorily valid). These comments for FROI & SROI on pg. 72 of KS IG.

95. This series of slides contains the speakers notes and may be used after the Training Session as a refresher course. This series of slides contains the speakers notes and may be used after the Training Session as a refresher course.

96. HOW TO GET STARTED Implementation Schedule In the Previous KDWC Training Session we learned about the New EDI Reports, their data content, when they are required and when they should be submitted. We also learned about Edits, Acknowledgements, and Corrections. This How to Get Started section will cover the Administrative and Testing processes required to successfully move into EDI production with KDWC. We will start with the Implementation Schedule. It is Voluntary! We will then discuss the Roles and Responsibilities of Claim Administrators, the KS EDI Coordinator, and KDWC. Additionally, we will discuss the Planning and Assessment of your current system, Scheduling a Test Date, Trading Partner Administration, and the Testing Procedure. In the Previous KDWC Training Session we learned about the New EDI Reports, their data content, when they are required and when they should be submitted. We also learned about Edits, Acknowledgements, and Corrections. This How to Get Started section will cover the Administrative and Testing processes required to successfully move into EDI production with KDWC. We will start with the Implementation Schedule. It is Voluntary! We will then discuss the Roles and Responsibilities of Claim Administrators, the KS EDI Coordinator, and KDWC. Additionally, we will discuss the Planning and Assessment of your current system, Scheduling a Test Date, Trading Partner Administration, and the Testing Procedure.

97. IMPLEMENTATIONSCHEDULE In regard to the Implementation Schedule, KDWC has published the Voluntary EDI reporting Date of 1/1/2004. To be approved for Production Status in KDWC there are specific tasks a Claim Administrator must complete. The first step for all Claim Administrators moving toward EDI Production status is to gather the appropriate resources. There are 3 critical resources you will need to ensure your success in EDI. The first is access to the KS Department of Human Resources Website. www.hr.state.ks.us/wc/html/wcediproject.htm Bookmark this on your computer. KS EDI News and Legislature, KS EDI Code lists, EDI FAQs, listing of EDI Staff and Vendor contacts. Second resource is KS EDI Implementation Guide. Download it from the KDHR website. You will become very familiar with this Guide. Start by reviewing the Executive Summary pg 19,20. Then review Steps to Implement EDI pages 22-24. Third critical resource is the IAIABC Release 1 Implementation Guide. Link to the IAIABC site is on the KS Website. Print out Section 6 which contains the Data Format and Dictionary section #6 Another Step toward approval for production is attending this KS EDI Informational Meeting designed to educate you regarding the KS�s EDI implementation. To initialize the process of sending EDI claims data to KS you will submit Trading Partner Documents. We will be reviewing how to fill out the Trading Partner Documents and where to submit them. Test Date Assignments Currently Available Although the published date for Production with KS is 1/1/04, it is likely that some Claim Administrators will complete their testing and be approved for Production prior to 1/1/04.In regard to the Implementation Schedule, KDWC has published the Voluntary EDI reporting Date of 1/1/2004. To be approved for Production Status in KDWC there are specific tasks a Claim Administrator must complete. The first step for all Claim Administrators moving toward EDI Production status is to gather the appropriate resources. There are 3 critical resources you will need to ensure your success in EDI. The first is access to the KS Department of Human Resources Website. www.hr.state.ks.us/wc/html/wcediproject.htm Bookmark this on your computer. KS EDI News and Legislature, KS EDI Code lists, EDI FAQs, listing of EDI Staff and Vendor contacts. Second resource is KS EDI Implementation Guide. Download it from the KDHR website. You will become very familiar with this Guide. Start by reviewing the Executive Summary pg 19,20. Then review Steps to Implement EDI pages 22-24. Third critical resource is the IAIABC Release 1 Implementation Guide. Link to the IAIABC site is on the KS Website. Print out Section 6 which contains the Data Format and Dictionary section #6 Another Step toward approval for production is attending this KS EDI Informational Meeting designed to educate you regarding the KS�s EDI implementation. To initialize the process of sending EDI claims data to KS you will submit Trading Partner Documents. We will be reviewing how to fill out the Trading Partner Documents and where to submit them. Test Date Assignments Currently Available Although the published date for Production with KS is 1/1/04, it is likely that some Claim Administrators will complete their testing and be approved for Production prior to 1/1/04.

98. ROLES & RESPONSIBILITIES Claim Administrator The Claim Administrator may be an Insurance Carrier, a Third Party Administrator (TPA), or Self Insured Employer (including Group Funded Compensation Pools ). The Claim Administrator is the organization that services worker�s compensation claims according to jurisdiction rules. 1. Recognize that EDI in KS is voluntary. (KS Statute and Rules Pg. 7) 2. Know your job as your Company�s management representative. (Executive Summary-Managing an EDI Implementation - Pg 19) 3. Know where to get Information and Help (Pg 21) 4. Assess your current operation and understand your options (Reporting Process Functions and Options Pg 80) 5. Understand KS EDI Reporting Requirements (Pg 38) 6. Plan your implementation (Steps to implement EDI Pg 22). 7. Secure a commitment from your IT Staff and/or EDI Vendor. 8. Revise branch office operations. 9. Submit your Trading Partner Forms at least 2 weeks before your arranged test date! (KS Trading Partner Process Pg 86) 10. Train Claim and IT Staff in their roles 11. Keep your Test Date 12. Maintain KS Data Quality requirements! The Claim Administrator may be an Insurance Carrier, a Third Party Administrator (TPA), or Self Insured Employer (including Group Funded Compensation Pools ). The Claim Administrator is the organization that services worker�s compensation claims according to jurisdiction rules. 1. Recognize that EDI in KS is voluntary. (KS Statute and Rules Pg. 7) 2. Know your job as your Company�s management representative. (Executive Summary-Managing an EDI Implementation - Pg 19) 3. Know where to get Information and Help (Pg 21) 4. Assess your current operation and understand your options (Reporting Process Functions and Options Pg 80) 5. Understand KS EDI Reporting Requirements (Pg 38) 6. Plan your implementation (Steps to implement EDI Pg 22). 7. Secure a commitment from your IT Staff and/or EDI Vendor. 8. Revise branch office operations. 9. Submit your Trading Partner Forms at least 2 weeks before your arranged test date! (KS Trading Partner Process Pg 86) 10. Train Claim and IT Staff in their roles 11. Keep your Test Date 12. Maintain KS Data Quality requirements!

99. ROLES & RESPONSIBILITIES Claim Administrator EDI Coordinator: Responsible to: 1. Manages all Test Date Assignments 2. Manages all Trading Partner Profile and Agreement submissions/changes. 3. Manages KDWC Testing 4. Monitors Test Results and On-Going Data Quality 5. Notify KS and Claim Administrator when a Claim Administrator falls below the KS Data Quality Requirements. 6 Provides general guidance and assistance for submitting Trading Partner Applications or Test corrections. 7. Will refer KS Trading Partners for assistance/information to the appropriate resource. 8. Will resolve KDWC system issues should they occur. * The KS EDI Coordinator does not teach EDI or Claims Reporting Requirements, and will not assume your responsibilities. However will point you to the appropriate resource to assist you.EDI Coordinator: Responsible to: 1. Manages all Test Date Assignments 2. Manages all Trading Partner Profile and Agreement submissions/changes. 3. Manages KDWC Testing 4. Monitors Test Results and On-Going Data Quality 5. Notify KS and Claim Administrator when a Claim Administrator falls below the KS Data Quality Requirements. 6 Provides general guidance and assistance for submitting Trading Partner Applications or Test corrections. 7. Will refer KS Trading Partners for assistance/information to the appropriate resource. 8. Will resolve KDWC system issues should they occur. * The KS EDI Coordinator does not teach EDI or Claims Reporting Requirements, and will not assume your responsibilities. However will point you to the appropriate resource to assist you.

100. ROLES & RESPONSIBILITIES Claim Administrator Kansas Department of Worker�s Compensation is Responsible to: 1. Maintain the Kansas Web-site Information 2. Respond to EDI Statute issues 3. Respond to Reporting Requirement questions and issues 4. Monitor Kansas EDI Implementation and continuing operations Operations. 5. Enforce / recourse �Out - of Compliance with EDI Statute� SituationsKansas Department of Worker�s Compensation is Responsible to: 1. Maintain the Kansas Web-site Information 2. Respond to EDI Statute issues 3. Respond to Reporting Requirement questions and issues 4. Monitor Kansas EDI Implementation and continuing operations Operations. 5. Enforce / recourse �Out - of Compliance with EDI Statute� Situations

101. Report proc 80, Tech lead summ 111 TEST DATE SCHEDULING Assessment & Planning Assessment and Planning � Review the Reporting Process Functions and Options (Pg 80) as well as the Business & Technical Lead Summary (Pg 111) as a guide to assess your EDI readiness and appropriate solution: Compare KDWC EDI Requirements (previous section) with your manual and computer system processes. Assess current ability to: Manage State Reporting Requirements. Capture State Report Data. Data Entry Products. Editing for Data Content and Quality. Translating Data into or from IAIABC or ANSI Formats. Managing Communications (Report Transmissions). Managing Acknowledgements, Replacement Reports, and Corrections. **Consider immediate and long term solutions Workers Compensation EDI Reporting Products In-house Vs. Vendor Products and Services **Build/Buy/Augment Web Entry Assessment and Planning � Review the Reporting Process Functions and Options (Pg 80) as well as the Business & Technical Lead Summary (Pg 111) as a guide to assess your EDI readiness and appropriate solution: Compare KDWC EDI Requirements (previous section) with your manual and computer system processes. Assess current ability to: Manage State Reporting Requirements. Capture State Report Data. Data Entry Products. Editing for Data Content and Quality. Translating Data into or from IAIABC or ANSI Formats. Managing Communications (Report Transmissions). Managing Acknowledgements, Replacement Reports, and Corrections. **Consider immediate and long term solutions Workers Compensation EDI Reporting Products In-house Vs. Vendor Products and Services **Build/Buy/Augment Web Entry

102. 86 TRADING PARTNER ADMINISTRATION Trading Partner Agreement See KDWC Trading Partner Process Pg. 86. WHO Must Submit these Forms? If you choose to Trade EDI with the state of Kansas - Insurer, Third Party Administrator, or Self Insured Employer (including Group Funded Compensation Pools) , you must complete a Trading Partner Agreement and a Trading Partner Profile. Trading Partner Agreement: Pg 90 Trading Partner Profile: Pg 93 Reporter�s Trading Partner Transmittal Form: Pg 99 You must submit these documents completely & correctly at least 2 weeks before your scheduled test date. Walk Attendees through completion of the FormsSee KDWC Trading Partner Process Pg. 86. WHO Must Submit these Forms? If you choose to Trade EDI with the state of Kansas - Insurer, Third Party Administrator, or Self Insured Employer (including Group Funded Compensation Pools) , you must complete a Trading Partner Agreement and a Trading Partner Profile. Trading Partner Agreement: Pg 90 Trading Partner Profile: Pg 93 Reporter�s Trading Partner Transmittal Form: Pg 99 You must submit these documents completely & correctly at least 2 weeks before your scheduled test date. Walk Attendees through completion of the Forms

103. 90 TRADING PARTNER AGREEMENT Data, Reports, Definition See KS EDI Trading Partner Agreement Pg. 90. The Agreement essentially defines responsibilities and agreement based upon the requirements: IAIABC Stds, Data Required, Reports Required, Business definitions, Data Quality Requirements, transmission costs and timeliness, etc. 1: Fill in your Organization Name 6: Date of Agreement & Signatures B1: Beginning Date (of Testing - Date you expect to go into production filing by ED1)See KS EDI Trading Partner Agreement Pg. 90. The Agreement essentially defines responsibilities and agreement based upon the requirements: IAIABC Stds, Data Required, Reports Required, Business definitions, Data Quality Requirements, transmission costs and timeliness, etc. 1: Fill in your Organization Name 6: Date of Agreement & Signatures B1: Beginning Date (of Testing - Date you expect to go into production filing by ED1)

104. 93 KANSAS TRADING PARTNER PROFILE KS Trading Partner Profile Pg. 93. Caution selection of Change & Delete: possible impact on receiving Acknowledgements, etc. Moratorium required. KS Trading Partner Profile Pg. 93. Caution selection of Change & Delete: possible impact on receiving Acknowledgements, etc. Moratorium required.

105. 93 KANSAS TRADING PARTNER PROFILE KS Trading Partner Profile Pg. 93. D: Plan to Use KS Web Data Entry is applicable to <100 Claims per year or special circumstances. E: 1: FEIN is Tax ID (9 digits) 2: TP ID is an optional 3 digit routing address (Only ATT Network Clients) 3: Postal Code KS Trading Partner Profile Pg. 93. D: Plan to Use KS Web Data Entry is applicable to <100 Claims per year or special circumstances. E: 1: FEIN is Tax ID (9 digits) 2: TP ID is an optional 3 digit routing address (Only ATT Network Clients) 3: Postal Code

106. 93 KANSAS TRADING PARTNER PROFILE KS Trading Partner Profile Pg. 93. Stress that H is a Business Contact, e.g. the person who speaks on behalf of management regarding EDI commitments, and resolves all business issues, data content/quality, etc. KS Trading Partner Profile Pg. 93. Stress that H is a Business Contact, e.g. the person who speaks on behalf of management regarding EDI commitments, and resolves all business issues, data content/quality, etc.

107. 93 KANSAS TRADING PARTNER PROFILE KS Trading Partner Profile Pg. 93. Define Vendor: Web Site / Data Entry / EDI communications or Translation services Define Technical Contact: Your organization�s IT contact who handles issues regarding your production system, data extract and feed to a vendor, or on-site or home grown EDI system issues. KS Trading Partner Profile Pg. 93. Define Vendor: Web Site / Data Entry / EDI communications or Translation services Define Technical Contact: Your organization�s IT contact who handles issues regarding your production system, data extract and feed to a vendor, or on-site or home grown EDI system issues.

108. 93 KANSAS TRADING PARTNER PROFILE KS Trading Partner Profile Pg. 93 Define File Types and explain that if they use a Vendor, File type is provided by the vendor. KS Trading Partner Profile Pg. 93 Define File Types and explain that if they use a Vendor, File type is provided by the vendor.

109. 99 REPORTER�S TRADING PARTNER TRANSMITTALFORM Reporter�s Trading Partner Transmittal Form Pg. 99. A �Reporter� is an insurer, third party administrator or other reporting entity that transmit reports electronically to a jurisdiction on behalf of other Trading Partners. The Reporter�s Trading Partner Transmittal Form is used to expedite the processing of and scheduling of a group of trading partners using the same �Reporter� Enter the EDI Contact information in the �From� section of the transmittal form. When �Reporter� is a TPA performing claim administration for the claims reported, a Trading Partner Agreement and Profile is only required of the TPA. If the �Reporter� is transmitting reports administrated by others, attach a Trading Partner Agreement and Profile for the �Reporter� and each organization it will be transmitting reports on behalf of. Each transmittal form allows for the entry of twenty five trading partners. Retain a copy of the transmittal packet Send the originals to the state contact listed in the �To� section of the form. Fax a copy to the KDWC EDI Coordinator. Reporter�s Trading Partner Transmittal Form Pg. 99. A �Reporter� is an insurer, third party administrator or other reporting entity that transmit reports electronically to a jurisdiction on behalf of other Trading Partners. The Reporter�s Trading Partner Transmittal Form is used to expedite the processing of and scheduling of a group of trading partners using the same �Reporter� Enter the EDI Contact information in the �From� section of the transmittal form. When �Reporter� is a TPA performing claim administration for the claims reported, a Trading Partner Agreement and Profile is only required of the TPA. If the �Reporter� is transmitting reports administrated by others, attach a Trading Partner Agreement and Profile for the �Reporter� and each organization it will be transmitting reports on behalf of. Each transmittal form allows for the entry of twenty five trading partners. Retain a copy of the transmittal packet Send the originals to the state contact listed in the �To� section of the form. Fax a copy to the KDWC EDI Coordinator.

110. 103-110 TESTING PROCEDURES See Kansas Test and Production Process Pg 103 The objective of testing is to ascertain a Trading Partner�s technical and business reporting competency. Trading Partners using approved data transport methods and demonstrated competence reporting to another WC jurisdiction are only required to send one test file to KDWC to validate connectivity. Step 1: Pretest Requirements: Schedule your test date. Complete Trading partner Agreement and Profile 2 weeks prior to test date. Plan to use �Real� claim data in testing. Review KDWC Test and Production Process (pg 103) Step 2: Technical capability Test: Test Day 1 Send successfully 1 IAIABC Header (T), Original, and Trailer record batch. Notify the KS EDI Coordinator that the file has been sent & VAN Mailbox. Pass if TA or TE AK1 received. Do not send a CO in response to a TE. KS EDI Coordinator will advise results/proceed Step 3 - Else contact EDI Coordinator after three days.See Kansas Test and Production Process Pg 103 The objective of testing is to ascertain a Trading Partner�s technical and business reporting competency. Trading Partners using approved data transport methods and demonstrated competence reporting to another WC jurisdiction are only required to send one test file to KDWC to validate connectivity. Step 1: Pretest Requirements: Schedule your test date. Complete Trading partner Agreement and Profile 2 weeks prior to test date. Plan to use �Real� claim data in testing. Review KDWC Test and Production Process (pg 103) Step 2: Technical capability Test: Test Day 1 Send successfully 1 IAIABC Header (T), Original, and Trailer record batch. Notify the KS EDI Coordinator that the file has been sent & VAN Mailbox. Pass if TA or TE AK1 received. Do not send a CO in response to a TE. KS EDI Coordinator will advise results/proceed Step 3 - Else contact EDI Coordinator after three days.

111. 103-110 TESTING PROCEDURES Step 3: Business Content Test: Send IAIABC Header (Test), 10 FROIs (Original, Denial, Acquired) using production system data, and Trailer. Receive Acknowledgements - send second Test batch containing 10 FROI transactions including Corrections (in response to TE), Change, and Cancel transactions. Testing and evaluation process continues until two consecutive batches of business content test files are processed and acknowledged. TP must meet data quality requirement of A minimum of 85% are TA or TE No more than 15% are rejected with TR A minimum of 80% correction compliance Step 4: Kansas EDI Coordinator will advise if Trading Partner passes FROI Data Content Test. (CC to State). When approved for FROI production TP may voluntarily begin EDI reporting and terminate paper reports to KDWC.Step 3: Business Content Test: Send IAIABC Header (Test), 10 FROIs (Original, Denial, Acquired) using production system data, and Trailer. Receive Acknowledgements - send second Test batch containing 10 FROI transactions including Corrections (in response to TE), Change, and Cancel transactions. Testing and evaluation process continues until two consecutive batches of business content test files are processed and acknowledged. TP must meet data quality requirement of A minimum of 85% are TA or TE No more than 15% are rejected with TR A minimum of 80% correction compliance Step 4: Kansas EDI Coordinator will advise if Trading Partner passes FROI Data Content Test. (CC to State). When approved for FROI production TP may voluntarily begin EDI reporting and terminate paper reports to KDWC.

112. 103-110 TESTING PROCEDURES Step 5: SROI Business Content Test (IP must precede the FN, an FN must precede an AN) Batch one: IAIABC Header (T), SROI (04, IP, AP or CD), Trailer. Based on previously sent FROI Test Batch. Minimum 10 SROI. Batch 2: IAIABC Header (T), at least one SROI Change and Correction, include some FN and AN, Trailer. Based on previous FROI or SROI Batch. Sent immediately after receiving Batch 1 Acknowledgements. If no SROI transactions with TE, send a test SROI FN in the second batch with at least one data element with an invalid value which should produce a TE. Batch 3: IAIABC Header (T), at least one SROI Correction, Trailer. Sent immediately after receiving Batch 1 Acknowledgements. Step 6: Approved for Production Data Quality �Must maintain KDWC 85-15-80 throughout production. If below the KDWC data quality requirements, the 85-15-80 standard for five (5) consecutive batches, KDWC requires the Claim Administrator to submit a written report to KDWC EDI Coordinator. (Pg 105) Submit a written report to the KDWC EDI Coordinator to include the cause and corrective action taken by the claim administrator for each error noted on the AK-1 Acknowledgement for the last five transmissions. Submit the Employer�s Report of Accident, K-WC 1101-A paper report and if applicable the Kansas Open/Closed Claim Study flat file record until further notice. Claim Administrators may be subject to a higher Data Quality standard Insurers may be subject to a fine or penalty for not meeting KDWC reporting or data quality requirements. (See Fines and Penalties). Step 5: SROI Business Content Test (IP must precede the FN, an FN must precede an AN) Batch one: IAIABC Header (T), SROI (04, IP, AP or CD), Trailer. Based on previously sent FROI Test Batch. Minimum 10 SROI. Batch 2: IAIABC Header (T), at least one SROI Change and Correction, include some FN and AN, Trailer. Based on previous FROI or SROI Batch. Sent immediately after receiving Batch 1 Acknowledgements. If no SROI transactions with TE, send a test SROI FN in the second batch with at least one data element with an invalid value which should produce a TE. Batch 3: IAIABC Header (T), at least one SROI Correction, Trailer. Sent immediately after receiving Batch 1 Acknowledgements. Step 6: Approved for Production Data Quality �Must maintain KDWC 85-15-80 throughout production. If below the KDWC data quality requirements, the 85-15-80 standard for five (5) consecutive batches, KDWC requires the Claim Administrator to submit a written report to KDWC EDI Coordinator. (Pg 105) Submit a written report to the KDWC EDI Coordinator to include the cause and corrective action taken by the claim administrator for each error noted on the AK-1 Acknowledgement for the last five transmissions. Submit the Employer�s Report of Accident, K-WC 1101-A paper report and if applicable the Kansas Open/Closed Claim Study flat file record until further notice. Claim Administrators may be subject to a higher Data Quality standard Insurers may be subject to a fine or penalty for not meeting KDWC reporting or data quality requirements. (See Fines and Penalties).

113. HOW TO GET STARTED REVIEW

114. TECHNOLOGY METHODS Kansas Web Entry File Formats Networks Vendors Technology methods include: File Formats - the format of the claims data Networks � the data transport method used to electronically move the claims data between the Claim Administrators system and the KDWC System Vendors � Companies that provide these services Kansas Web Entry � For Claims Administrators who meet the qualifications of less than 100 claims per year or approved by KDWC for special circumstances.Technology methods include: File Formats - the format of the claims data Networks � the data transport method used to electronically move the claims data between the Claim Administrators system and the KDWC System Vendors � Companies that provide these services Kansas Web Entry � For Claims Administrators who meet the qualifications of less than 100 claims per year or approved by KDWC for special circumstances.

115. KANSAS WEB ENTRY Qualifications < 100 claims/yr or special circumstances www.hr.state.ks.us/wc/html/ wcedinews.htm (SC-Web) Data Entry of First Report of Injury Data Entry of Subsequent Reports Online Error Detection/Correction SC-Web SC Web is available for Carriers, Self Administered, Group Funded Pools, or TPA�s for reporting Workers� Compensation claim data. Product overview in light of Electronic Data Interchange. SC-Web SC Web is available for Carriers, Self Administered, Group Funded Pools, or TPA�s for reporting Workers� Compensation claim data. Product overview in light of Electronic Data Interchange.

116. SC-WEB REQUIREMENTS Meet User Qualifications File Trading Partner Documents Obtain a User ID and Password--EDI Coordinator Microsoft Browser 5.0 or Above Internet Access The two electronic File Format types that are accepted by the KDWC EDI System are IAIABC Flat File and ANSI ASC X12. These file formats identify the technical positioning of the EDI data. The two electronic File Format types that are accepted by the KDWC EDI System are IAIABC Flat File and ANSI ASC X12. These file formats identify the technical positioning of the EDI data.

117. SC-WEB REQUIREMENTS Login Screen Welcome Screen General System Operations Login Screen - Logging in to SC-Web, Logging out of SC-Web How to log in and out of the system, using ID and Password provided by the client System Administrator. Also, instruction on how to complete the new user registration form, for Administrator�s who will be creating user accounts. Welcome Screen - Viewing or Modifying Claim Information The main menu, at which point a First Report (FROI) or Subsequent of Injury (SROI) can be created, or an existing FROI, SROI, or Acknowledgement can be browsed or searched. Help on all system functions, as well as user account maintenance is accessible from here. General System Operations Mandatory/Conditional/Optional Fields Color-coding system in which each jurisdiction�s reporting requirements are easily visible. After the document type and jurisdiction are selected, the fields are color coded for ease of input. Mandatory, Conditional, and Optional (MCO) fields are easily distinguished. The MCO requirements for all EDI states accepting IAIABC files in X12 format have been pre-programmed into the system. When requirements change, an update file is distributed, and then installed by the client � a process requiring less than 5 minutes. Business/System Edits Edit checks are performed prior to submission to any jurisdiction, to minimize reporting error. Business edits are IAIABC edits such as, �Is date of hire prior to date of injury?� When new IAIABC standards are released, such as Iowa Release 2, these are coded into the product and distributed. System edits are formatting and integrity edits which verify that numeric fields contain numbers, date fields contain dates, etc. Support Tables Each time a new claim is added, users have the option of saving employer, insurer, and other ancillary data in support tables. The saved information is then accessible next time a claim is entered, and can easily be added to the claim, minimizing duplicate data entry. System Time Out After a period of inactivity, the system will log off a user. This time out helps to minimize database connections and maximize application security. Saving vs. Submitting Entered claim information may be saved locally, using the Save function. This may be done when there are some fields missing, or questions about data validity, prior to submitting. After a record is complete, and passes all edit checks, it may be Submitted (or Sent) to a jurisdiction. Saved claims are NOT sent until the Submit function is used. Printing Reports are formatted for the display on-screen. However, users can print the claim information by clicking on the Printer-Friendly Version link. This will reformat the record so that it is suitable for printing. These file formats identify the technical positioning of the EDI data. Login Screen - Logging in to SC-Web, Logging out of SC-Web How to log in and out of the system, using ID and Password provided by the client System Administrator. Also, instruction on how to complete the new user registration form, for Administrator�s who will be creating user accounts. Welcome Screen - Viewing or Modifying Claim Information The main menu, at which point a First Report (FROI) or Subsequent of Injury (SROI) can be created, or an existing FROI, SROI, or Acknowledgement can be browsed or searched. Help on all system functions, as well as user account maintenance is accessible from here. General System Operations Mandatory/Conditional/Optional Fields Color-coding system in which each jurisdiction�s reporting requirements are easily visible. After the document type and jurisdiction are selected, the fields are color coded for ease of input. Mandatory, Conditional, and Optional (MCO) fields are easily distinguished. The MCO requirements for all EDI states accepting IAIABC files in X12 format have been pre-programmed into the system. When requirements change, an update file is distributed, and then installed by the client � a process requiring less than 5 minutes. Business/System Edits Edit checks are performed prior to submission to any jurisdiction, to minimize reporting error. Business edits are IAIABC edits such as, �Is date of hire prior to date of injury?� When new IAIABC standards are released, such as Iowa Release 2, these are coded into the product and distributed. System edits are formatting and integrity edits which verify that numeric fields contain numbers, date fields contain dates, etc.

118. SC-WEB Functions First Reports of Injury Subsequent Reports of Injury Acknowledgements Workflow First Reports of Injury Creating First Reports After selecting jurisdiction and report type, users may enter claim information, and then click Submit (at which point edit checks are run). If errors are present, a dialog appears with error messages, and hyperlinks leading to the errant field(s). Once corrected, the Submit button can be clicked again. If no errors exist, a dialog appears indicated successful submission. Browsing First Reports Clicking on Browse will produce a summary screen with a few lines of key information regarding each claim, displayed in Employee Last Name alphabetical order. From this screen FROI�s may be viewed or edited. Searching First Reports 19 different fields can be selected for searching; including ranges and wildcards, thus providing users the capability of extracting detailed information. Additionally, the information may be sorted in a number of different ways. Subsequent Reports of Injury SROI�s work in much the same way as FROI�s. The ability to enter, browse, edit, search, save, submit, run edit checks, all can be performed on SROI�s. However, the SROI�s can be created from �scratch� just like FROI�s, or they may be generated based on a particular FROI, which preceded. Creating Subsequent Reports Associated with First Reports To create a SROI based on an existing FROI, first open a FROI and click the Create SROI button. By doing so, a number of fields will populate the SROI with information previously entered on the FROI. Creating Stand-alone Subsequent Reports SROI�s can be created as a new claim, with no associated FROI by following the same basic procedures as creating a FROI, only using the SROI links. Release 1 SROI�s may be converted to Release 2, in the same manner as FROI�s. Release 2 SROI�s may be created from a Release 1 FROI. This flexibility is designed to handle a multitude of claims entry scenarios. Browsing/Searching Subsequent Reports These functions parallel those of the FROI. SROI�s may be browsed, via a summary screen, or searched for using one or a multiple of criteria. First Reports of Injury Creating First Reports After selecting jurisdiction and report type, users may enter claim information, and then click Submit (at which point edit checks are run). If errors are present, a dialog appears with error messages, and hyperlinks leading to the errant field(s). Once corrected, the Submit button can be clicked again. If no errors exist, a dialog appears indicated successful submission. Browsing First Reports Clicking on Browse will produce a summary screen with a few lines of key information regarding each claim, displayed in Employee Last Name alphabetical order. From this screen FROI�s may be viewed or edited. Searching First Reports 19 different fields can be selected for searching; including ranges and wildcards, thus providing users the capability of extracting detailed information. Additionally, the information may be sorted in a number of different ways. Subsequent Reports of Injury SROI�s work in much the same way as FROI�s. The ability to enter, browse, edit, search, save, submit, run edit checks, all can be performed on SROI�s. However, the SROI�s can be created from �scratch� just like FROI�s, or they may be generated based on a particular FROI, which preceded. Creating Subsequent Reports Associated with First Reports To create a SROI based on an existing FROI, first open a FROI and click the Create SROI button. By doing so, a number of fields will populate the SROI with information previously entered on the FROI. Creating Stand-alone Subsequent Reports SROI�s can be created as a new claim, with no associated FROI by following the same basic procedures as creating a FROI, only using the SROI links. Release 1 SROI�s may be converted to Release 2, in the same manner as FROI�s. Release 2 SROI�s may be created from a Release 1 FROI. This flexibility is designed to handle a multitude of claims entry scenarios. Browsing/Searching Subsequent Reports These functions parallel those of the FROI. SROI�s may be browsed, via a summary screen, or searched for using one or a multiple of criteria.

119. SC-WEB ENTRY

120. FILE FORMATS IAIABC Flat File ANSI ASC X12 The KDWC EDI System accepts electronic data (this is the format the claims data is in when it travels through the network) in two electronic File Format types; the IAIABC Flat File and ANSI ASC X12. These file formats identify the technical positioning of the EDI data. I will be presenting an overview of each file layout. Your challenge is to get your claims data into one of these formats. You can create the claims data file yourself, or if you use a vendor solution they would be responsible for creating the files. IAIABC Flat File � a basic file made up of specifically defined elements that do not vary. Each field, or data element, of claims data is assigned an element number, the format of each element is defined as to position in the file and whether it is N (numeric), A/N (alphanumeric), $ (dollar value), time or date. The element is of a specific character length. Fillers of leading zeros or trailing spaces ensure the correct length of the field. Lego analogy. This type of file is the easiest to map from a Claims Management system. ANSI ASC X12 � uses an 8 tier hierarchical structure. Within each tier or hierarchical level are segments and within each segment the data format is defined by position. The elements in the X12 file are separated by delimiters. Like email. Many data elements have variable lengths. NOT FOR THE TIMIDThe KDWC EDI System accepts electronic data (this is the format the claims data is in when it travels through the network) in two electronic File Format types; the IAIABC Flat File and ANSI ASC X12. These file formats identify the technical positioning of the EDI data. I will be presenting an overview of each file layout. Your challenge is to get your claims data into one of these formats. You can create the claims data file yourself, or if you use a vendor solution they would be responsible for creating the files. IAIABC Flat File � a basic file made up of specifically defined elements that do not vary. Each field, or data element, of claims data is assigned an element number, the format of each element is defined as to position in the file and whether it is N (numeric), A/N (alphanumeric), $ (dollar value), time or date. The element is of a specific character length. Fillers of leading zeros or trailing spaces ensure the correct length of the field. Lego analogy. This type of file is the easiest to map from a Claims Management system. ANSI ASC X12 � uses an 8 tier hierarchical structure. Within each tier or hierarchical level are segments and within each segment the data format is defined by position. The elements in the X12 file are separated by delimiters. Like email. Many data elements have variable lengths. NOT FOR THE TIMID

121. FLAT FILE FORMAT IAIABC Developed and Maintained Records/Transactions A Record is a group of related �Data Elements� that form a transaction. A Transaction can consist of 1 or more �Records� to communicate an event such as a claim event or policy event. IAIABC Release 1 FROI (148), SROI (A49) and Acknowledgement (AK1) transactions require 1 record each to communicate an event. Each Transaction Type (transaction) is contained in a batch which is preceded by a Header Record and concluded with a Trailer Record. Records/Transactions A Record is a group of related �Data Elements� that form a transaction. A Transaction can consist of 1 or more �Records� to communicate an event such as a claim event or policy event. IAIABC Release 1 FROI (148), SROI (A49) and Acknowledgement (AK1) transactions require 1 record each to communicate an event. Each Transaction Type (transaction) is contained in a batch which is preceded by a Header Record and concluded with a Trailer Record.

122. 76 HD1 - R1 Header Record87 Byte Fixed Length Record 9 Data Elements Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6 Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6

123. Transmission Sample (Shown partial and wrapped for display): HD1666777888 888777666486029925 66612122720030624074530 P14801 1480020010327PR 666777888ABC INSURER 818181818TPA 406 TOPEKA WAY SUITE 6 TOPEKA TR1000000001 HD1 - R1 Header Record87 Byte Fixed Length Record 9 Data Elements The Header Record (HD1) precedes each batch of data. It is the first record in every batch. The Header Record uniquely identifies the sender, the receiver, the date and time the batch was prepared, whether the batch contains test or production data and the Transaction types/IAIABC Release contained within the batch. The Header Record along with the Trailer Record forms an �envelope� that surrounds a batch of transactions. The Header Record (HD1) precedes each batch of data. It is the first record in every batch. The Header Record uniquely identifies the sender, the receiver, the date and time the batch was prepared, whether the batch contains test or production data and the Transaction types/IAIABC Release contained within the batch. The Header Record along with the Trailer Record forms an �envelope� that surrounds a batch of transactions.

124. 56 & 57 148� R1 First Report of Injury913 Byte Fixed Length Record68 Data Elements Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6

125. Transmission Sample (Shown partial and wrapped for display): HD1666777888 888777666486029925 66612122720030624074530 P14801 1480020010327PR 666777888ABC INSURER 818181818TPA 406 TOPEKA WAY SUITE 6 TOPEKA TR1000000001 148� R1 First Report of Injury913 Byte Fixed Length Record68 Data Elements 148 � R1 Batch/Transmission Batch: Consists of 1 Header Record, one or more detail transactions and 1 Trailer Record. Transmission: Consists of 1 or more batches sent or received during a communication session. 148 � R1 Batch/Transmission Batch: Consists of 1 Header Record, one or more detail transactions and 1 Trailer Record. Transmission: Consists of 1 or more batches sent or received during a communication session.

126. 76 TR1 - R1 Trailer Record12 Byte Fixed Length Record 2 Data Elements Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6

127. Transmission Sample (Shown partial and wrapped for display): HD1666777888 888777666486029925 66612122720030624074530 P14801 1480020010327PR 666777888ABC INSURER 818181818TPA 406 TOPEKA WAY SUITE 6 TOPEKA TR1000000001 TR1 - R1 Trailer Record12 Byte Fixed Length Record 2 Data Elements Trailer Record The Trailer Record (TR1) designates the end of a batch of transactions. It provides a count of records/transactions within a batch. The Trailer Record is used to ensure that the entire batch is complete and valid. The Header and Trailer Records form an �envelope� that surrounds a batch of transactions. Trailer Record The Trailer Record (TR1) designates the end of a batch of transactions. It provides a count of records/transactions within a batch. The Trailer Record is used to ensure that the entire batch is complete and valid. The Header and Trailer Records form an �envelope� that surrounds a batch of transactions.

128. 77 AK1 � R1 AcknowledgmentVariable Length RecordMinimum Length = 208 - - Maximum Length = 1099 208 + 99{# of errors} x 9 {# of bytes in variable segment} = 1099 20 Data Elements Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6Data Elements Defined Data Element Number Assigned values or codes, if applicable Assigned valid applicable edits based on Error Messages Assigned a format, e.g. Alphanumeric, Number Format, Date, Time Monetary Amount. Available in IAIABC IG Data Format and Dictionary section #6

129. Transmission Sample (Shown partial and wrapped for display): HD1666777888 888777666486029925 66612122720030624074530 P14801 AK10000000012001032708164466677788834236 818181818A49TAINSRPTNUM WC29443 012234995 IP20010314 0 00 TR1000000001 AK1 � R1 AcknowledgmentVariable Length RecordMinimum Length = 208 - - Maximum Length = 1099 208 + 99{# of errors} x 9 {# of bytes in variable segment} = 1099 20 Data Elements AK1 Acknowledgment Record A transaction returned as a result of an original report. It contains enough data elements to identify the original transaction and any technical and business issues found with it.AK1 Acknowledgment Record A transaction returned as a result of an original report. It contains enough data elements to identify the original transaction and any technical and business issues found with it.

130. ANSI ACS X12 FORMAT IAIABC Assists in Development and Work Comp Implementation American National Standards Institute X12 Electronic Data Interchange ANSI � American National Standards Institute founded in 1918. Recognized coordinator of US voluntary standards. Provide requirements, terminology, a vast array of testing standards and EDI standards. ASC � In 1979, ANSI chartered a new committee, now known as Accredited Standards Committee (ASC) X12. The committee was formed to develop uniform standards for electronic interchange of business transactions. The X12 standards provide a means to encode business documents so that they can be interpreted by a computer application. The documents are organized data, meaning data is separated by �delimiter� characters rather than by fields or records. The standards provide means to organize the data.ANSI � American National Standards Institute founded in 1918. Recognized coordinator of US voluntary standards. Provide requirements, terminology, a vast array of testing standards and EDI standards. ASC � In 1979, ANSI chartered a new committee, now known as Accredited Standards Committee (ASC) X12. The committee was formed to develop uniform standards for electronic interchange of business transactions. The X12 standards provide a means to encode business documents so that they can be interpreted by a computer application. The documents are organized data, meaning data is separated by �delimiter� characters rather than by fields or records. The standards provide means to organize the data.

131. ANSI ACS X12 FORMAT 148 First Report of Injury A49 Subsequent Report of Injury 997 Batch Level Acknowledgment 824 Detailed Acknowledgment

132. 148�X12 First Report of Injury The 148 is divided into 3 tables. Table 1 is the Header or ISA Loop containing the information about the sender and receiver of the transaction Table 2 is the Detail level containing the specific claim information Table 3 is the Summary level containing the numeric counts of the claims being sent in the transactions.The 148 is divided into 3 tables. Table 1 is the Header or ISA Loop containing the information about the sender and receiver of the transaction Table 2 is the Detail level containing the specific claim information Table 3 is the Summary level containing the numeric counts of the claims being sent in the transactions.

133. NETWORKS Value Added Networks Proprietary Networks Networks � the data transport method used to electronically move the claims data between the Claim Administrators system and the KDWC System. In other words, how the data is transmitted between the Claim Administrators System and KDWC�s. KDWC EDI reports must be sent through an approved Network or data transport method. The two network types available are Value Added Networks or Vendor Provided or vendor described in the Test and Production Process technical and business competency requirements. Please also see the �Submitting Options to Consider� and �Information and Help� section of this Guide and the IAIABC web site for more details. Networks � the data transport method used to electronically move the claims data between the Claim Administrators system and the KDWC System. In other words, how the data is transmitted between the Claim Administrators System and KDWC�s. KDWC EDI reports must be sent through an approved Network or data transport method. The two network types available are Value Added Networks or Vendor Provided or vendor described in the Test and Production Process technical and business competency requirements. Please also see the �Submitting Options to Consider� and �Information and Help� section of this Guide and the IAIABC web site for more details.

134. 82 VALUE ADDED NETWORKS Secure Public Networks Audit Capabilities Data Recovery Capabilities Interconnects to other VANS Per Character Transmission Costs A Value Added Network (VAN) is a facility used to exchange electronic files between organizations. A VAN can be viewed as a huge community �hard drive� that contains separate storage (Mail Boxes) for its subscribers. It provides a place for the Claim Administrator to send State Reports to and a place to pick up acknowledgements from the states. Such facilities run 24 hours a day and provide �Federal Quality� data security, reliable backup and reliable data transfer with communication level acknowledgement. It relieves each subscriber from considerable hardware, software, and personnel investments and virtually extends your organization�s hours of operation. Unless EDI Volume is very large, or an Organization has excess capacity, VANs probably provide a significant cost advantage. Some protocol differences exist between the major VANS, but once established, VANs provide expansive connectivity between States and Claim Administrators.A Value Added Network (VAN) is a facility used to exchange electronic files between organizations. A VAN can be viewed as a huge community �hard drive� that contains separate storage (Mail Boxes) for its subscribers. It provides a place for the Claim Administrator to send State Reports to and a place to pick up acknowledgements from the states. Such facilities run 24 hours a day and provide �Federal Quality� data security, reliable backup and reliable data transfer with communication level acknowledgement. It relieves each subscriber from considerable hardware, software, and personnel investments and virtually extends your organization�s hours of operation. Unless EDI Volume is very large, or an Organization has excess capacity, VANs probably provide a significant cost advantage. Some protocol differences exist between the major VANS, but once established, VANs provide expansive connectivity between States and Claim Administrators.

135. 84 PROPRIETARY NETWORKS Secure Transmission Audit Capabilities Data Recovery Capabilities Per Report Transmission Costs

136. 116 EDI VENDORS Bridium www.bridium.com (866) 448-1776 sisaac@bridium.com This is a list of EDI vendors currently submitting workers compensation claim reports in other jurisdictions and have proven technical & business capability to comply with the Kansas EDI Implementation Guide. This list is for informational purposes only and KDWC does not endorse and/or recommend the services of any one vendor. Refer to the IAIABC, and other EDI standard setting organizations for additional EDI vendors. This is a list of EDI vendors currently submitting workers compensation claim reports in other jurisdictions and have proven technical & business capability to comply with the Kansas EDI Implementation Guide. This list is for informational purposes only and KDWC does not endorse and/or recommend the services of any one vendor. Refer to the IAIABC, and other EDI standard setting organizations for additional EDI vendors.

137. TECHNOLOGY METHODS REVIEW

KANSAS EDI TRAINING SEMINAR

KANSAS EDI TRAINING SEMINAR

Presentation Transcript

EDI Product Training

Officers Training Seminar

CROWNWeb EDI Training

ELDER’S TRAINING SEMINAR

EDI Training October 2012 Alberta

ELDER’S TRAINING SEMINAR

Kansas WIC Vendor Training

CWP Training Seminar

ELDER’S TRAINING SEMINAR

ELDER’S TRAINING SEMINAR

ELDER’S TRAINING SEMINAR

ELDER’S TRAINING SEMINAR

Training Seminar

ELDER’S TRAINING SEMINAR

EDI

Embedding EDI Training Session

Supplier Training New EDI transactions

ELDER’S TRAINING SEMINAR

EDI

EDI Training in Hyderabad | EDI Online Training in India | EDI Training Institutes in Hyderabad

EDI Training in Hyderabad | EDI Online Training in India | EDI Training Institutes in Hyderabad

EDI Online Training | EDI Training | Hyderabad | India | USA | UK