Final Report. April 18, Clark Bedsole Adam Davie Tim Jansen Robert Jones

Transcription

1 EDI Library Final Report April 18, 2008 Clark Bedsole Adam Davie Tim Jansen Robert Jones

2 Table of Contents Introduction System Description System Diagrams Hardware Overview... 9 Software Overview Hardware Detailed Design Software Detailed Design Test Procedure and Results Results Conclusions Recommendations for Future Work Appendixes Appendix A: Data Sheets Appendix B: User s Manual Appendix C: Diagrams and Drawings Appendix D: Customer Contact Information Appendix E: Simulation Results Appendix F: Source Code EDI_LIB_MANAGE_RECORDS procedure EDI_LIB_MANAGE_SUBSCRIPTIONS procedure P age

3 Introduction Health service providers are responsible for providing information about their patients to payers like insurance companies. This is necessary for the insurance companies to verify if a patient s claim for reimbursement is valid or not. This transaction of information is done over the internet and is referred to as electronic data interchange, or EDI. Each payer requires different information about the patient and the services they received. Because there are several types of health services available and a multitude of payers, the combination of possibilities becomes immense. For this reason, standards have been established by payers to attempt to organize this information in a way that can be processed more easily. Therefore, health service providers will need to keep track of their patients information in addition to the formatting rules (hereafter EDI specifications) payers require for a claim. Due to the number of health service providers out there, there is a high demand for third party applications to make the management of all this information simple. Our project sponsor, Qualifacts, is one such company specializing in this business. Their software product is a database driven web interface called CareLogic. The essential functionality of their product is already in place and currently being used by their many customers. A problem that has become evident during the history of CareLogic deals with the management of the EDI specifications. EDI specification details were being kept only locally on a single customer s database. When another customer required the same EDI specification details, they would have to be manually copied over to their database from the one with it currently. This became a tedious task as the number of customers increased, especially since payers update their specification requirements often. The goal of this project was to design and implement a sort of library for keeping track of 3 Page

4 all EDI specifications as well as which specifications customers needed to have for their patients. Our design would require a global database with tables containing EDI specifications for all payers used by all customers. The tables that hold specification details are currently already implemented in CareLogic and we would be adding a table for associating these specifications with payers. The CareLogic front end would be extended with an addition for allowing Qualifacts to easily add or remove subscribers for any given EDI specification. This will require an additional table in the database to manage the relationship between EDI specification records and customer subscribers. These subscriptions will help Qualifacts identify which of their customers databases need to be updated when a payer changes their EDI spec or when a new payer EDI spec is required for filing a claim. System Description The EDI library was designed to fulfill three primary functional requirements: 1. Manage payers/clearinghouses and their associated EDI specifications 2. Manage health services organizations and the payers/clearinghouses with which they interact 3. Search for payers/clearinghouses Within the context of the EDI library, managing payers/clearinghouses or health services organizations could involve one of several actions, including viewing, adding, editing, or 4 P age

5 deleting. In addition to these functional requirements, the EDI library was required to integrate with Qualifacts CareLogic application suite. CareLogic is implemented on an Oracle relational database, but uses a web based graphical interface. Using server side scripting technology, CareLogic can dynamically generate web pages which are populated with user requested information from the database. In order to ensure consistency with the rest of CareLogic, the EDI library was required to make use of pre existing functionality within CareLogic in order to generate its user interface. The principal data contained in the EDI library is the collection of payers/clearinghouses and their associated EDI specifications. Therefore, these elements are called EDI library records. The other data contained in the EDI library are the health services organizations that use the EDI library records. Since these organizations can conceptually be considered subscribing to EDI library records, the organizations are called subscribers within the EDI library. In the Oracle database environment, tables are used to store and organize data. The EDI library contains two tables one for EDI library records, and one for subscribers to those records. These tables are called, respectively, EDI_LIB_RECORDS and EDI_LIB_SUBSCRIPTIONS. The code contained in the EDI library is written in Oracle s procedural programming language called PL/SQL. In the Oracle database environment, packages are used to store and organize PL/SQL code. The EDI library contains two packages one for the management of EDI library records, and one for the management of subscribers to those records. These packages are called, respectively, EDI_LIB_MANAGE_RECORDS$ and EDI_LIB_MANAGE_SUBSCRIPTIONS$. 5 P age

6 Within each package, the code is further organized into operational units called procedures and functions. System Diagrams Symbol Legend Description EDI file request/download EDI file upload to payer Database Customer Server Customer Database Qualifacts Data Center Health Services Organization Internet Payer 1 Payer 2 Payer 3 Figure 1. Visual overview of the process involved for an EDI transaction. A health service provider uses the CareLogic web application locally and accesses a server at the Qualifacts data center. The server stores all the information for generating the appropriate EDI file which the user receives 6 P age

7 through the CareLogic front end. Once the provider has the EDI file they can send it to the appropriate payer. Figure 2. This is an ER (entity relationship) Diagram showing the tables we created in the database as well as their relationship to each other and the existing tables that were part of the CareLogic system. Primary keys (PK) in the tables constitute unique records that cannot be duplicated and foreign keys (FK) represent a relationship between fields in two separate tables. 7 P age

8 Figure 3. This diagram depicts the visual flow of the web pages associated with the EDI library. The leftto right layout designates the hierarchy of the pages (the left most being higher up in the structure). Arrows are used to indicate which pages can be reached from other pages. 8 P age

9 Hardware Overview The EDI library is implemented on an Oracle database running on a server residing in Qualifacts data center. The server is accessed via a PC equipped with both VPN connectivity and software capable of connecting to an Oracle database. Software Overview The EDI library physically manifests itself as a collection of nine interconnected web pages within the CareLogic web site. Each page of the EDI library is generated by a PL/SQL procedure or function contained within one of the two EDI library packages. In order to ensure a consistent graphical interface throughout the CareLogic web site, the CareLogic application suite contains a large collection of PL/SQL functions that are used generate the various elements that might appear on a web page, such as buttons, lists, text fields, drop down selections, and radio buttons. Therefore, the procedures and functions of the EDI library make calls to these existing functions, which are contained in other various packages, in order to generate the user interface elements necessary for each web page of the EDI library. The generation of the HTML code required for a web page in CareLogic is a two stage process. In the first stage, one or more PL/SQL procedures or functions generate XML tags represented as strings and write them to the page. In the second stage, the web browser retrieves an XML style sheet referenced by the XML, translates the XML into HTML, and displays the resulting web page. 9 P age

10 The following is a listing of each of the nine pages in the EDI library along with a brief description of that page s function, if necessary. 1. EDI Library First page presented to the user upon entering the EDI library Search for EDI library records View EDI library records 2. Select EDI Library Record View and edit an EDI library record 3. Add EDI Library Record 4. Delete EDI Library Record 5. EDI Specification View and edit the EDI specification associated with an EDI library record 6. Subscribers View subscribers of an EDI library record 7. Select Subscriber View organizational information about a subscriber View subscriber s subscriptions to EDI library records 8. Add Subscriber 9. Delete Subscriber 10 P age

11 Each of the nine web pages of the EDI library serves to fulfill all or part of one or more of the requirements. The following lists each requirement along with the titles of the pages that contribute towards meeting that requirement. 1. Manage payers/clearinghouses and their associated EDI specifications EDI Library Select EDI Library Record Add EDI Library Record Delete EDI Library Record EDI Specification 2. Manage health services organizations and the payers/clearinghouses with which they interact Subscribers Select Subscriber Add Subscriber Delete Subscriber 3. Search for payers/clearinghouses EDI Library Hardware Detailed Design No detailed hardware design was necessary. 11 P age

12 Software Detailed Design EDI Library The EDI Library page is the first page presented to the user upon entering the EDI library. This page initially contains a search form at the top and a listing of the EDI library records with the most recent effective dates at the bottom. The fields available in the search form include effective date, end date, payer/clearinghouse name, state, payer plan, county, and EDI type. When the user submits a search query, the page reloads and the listing at the bottom of the page is replaced with the results of the user s search query. On each row of the listing of EDI library records, four buttons appear at the left hand side: select, delete, specification, and subscribers. These buttons navigate to various pages related to the EDI library record on that row. The following procedures are used to create the functionality available on the EDI Library page: search_records, search_form, search_list, populatebeforeafterrecord, addsearchfieldtoquery, and geteditype. EDI Specification At the top of the EDI Specification page, information about the payer/clearinghouse that this EDI specification is associated with is listed. At the bottom of this page is a listing of the levels contained in this EDI specification. For each level that is listed, two buttons appear at the righthand side of that level s row, allowing the user to add/remove or edit the segments comprising that level. In the menu bar at the top right corner of the page reside buttons allowing the user to edit the EDI type information of this EDI specification and to add/edit the levels in the EDI 12 P age

13 specification. The functionality of the EDI Specification page is enabled entirely by the select_specification procedure. Add/Select EDI Library Record The add_record and select_record record procedure was designed with the idea of being able to do both things using the same form. The Add side of this procedure is designed with no variables being passed in, effectively leaving all of the form fields empty. After a record is filled out and submitted, the system gives the record a unique identification tag and the new record is the added to the database. The Select side of the procedure loads in a previously made record based off of its identification tag. The record then has all of the information associated with this tag loaded onto the page. Because the record is loaded with the identification tag, when modifications are made, the system is already aware that this is an existing record and it only needs to update the record on the database. Subscribers The list_subscriptions procedure displays all of the subscribers to a specific EDI specification that is clicked on from the EDI records page. The procedure expects a valid EDI_SPEC_ID from the EDI_LIB_RECORDS table to be passed in from its caller. This will uniquely identify the EDI specification that subscribers will be listed for. The procedure queries additional information from the EDI_LIB_RECORDS table about the EDI spec and displays this at the top of the generated page so it is clear to the user which spec subscribers are being listed for. Next, the procedure queries for all ORGANIZATION_ID fields in the EDI_LIB_SUBSCRIPTIONS table 13 P age

14 matching the specific EDI_SPEC_ID. Each ORGANIZATION_ID result is used to pull additional information about an organization (name, state, etc.) from matching records in the ORGANIZATION table. Select Subscriber The select_subscriber procedure functions similarly to the list_subscriptions procedure but utilizes a different view of the data. Instead of listing the subscribers to a specific EDI spec, this procedure lists the EDI specs subscribed to by a specific customer (subscriber). As would be expected, this procedure requires a valid ORGANIZATION_ID from the ORGANIZATION table to be passed in. This is needed to uniquely identify which organization EDI spec subscriptions will be listed for. First, the procedure queries the ORGANIZATION table to acquire the details about the organization (name, state, etc.) to be listed at the top of the page. This information is more descriptive to a user than simply the id of the organization. Next, the procedure queries for all EDI_SPEC_ID fields in the EDI_LIB_SUBSCRIPTIONS table matching the specific ORGANIZATION_ID. Each EDI_SPEC_ID result is used to pull additional information about the EDI spec (payer name, payer plan, etc.) from matching records in the EDI_LIB_RECORDS table. Add/Remove Subscriber The add_subscriber and remove_subscriber procedures insert records into and delete records from the EDI_LIB_SUBSCRIPTIONS table respectively. Inserting a record equates to an organization subscribing to an EDI spec, and deleting equates to an organization unsubscribing. An insertion into the table requires a valid EDI_SPEC_ID and ORGANIZATION_ID from the 14 P age

15 EDI_LIB_RECORDS and ORGANIZATION tables respectively. Inserting into the table implies a relationship between a single EDI specification and one organization. These two fields form the primary key for the table and therefore an organization cannot be subscribed to the same EDI spec twice. The add_subscriber procedure takes this into effect so the user is not able to accidentally try something like this. It also requires a valid EDI_SPEC_ID to be passed in to identify which spec an organization will be subscribed to. It uses to the EDI_SPEC_ID to query for ORGANIZATION_ID values not already associated with the given EDI spec. The procedure then lists the organization names with those ids in a drop down box allowing the user to select an organization and add it as a subscriber to the EDI spec. The remove_subscriber procedure simply takes a valid EDI_SPEC_ID and ORGANIZATION_ID as input parameters and deletes from the EDI_LIB_SUBSCRIPTIONS where these values match. This will effectively unsubscribe an organization from a particular EDI spec. The procedure does not require any addition constraint checks because a user will only have to option to use the unsubscribe button for organizations already subscribed to an EDI spec. Delete EDI Library Record The delete_record procedure deletes a record from the EDI_LIB_RECORDS table matching the EDI_SPEC_ID, which needs to be passed into the procedure. A record serves as an identifier for the EDI spec details that are already saved in the database and associates them with a payer. The EDI record is also linked to any number of organization subscriptions and should not be removed if subscriptions to the record exist or these links will be broken. This feature requires some checks to be made in order to notify a user of the front end application that a record with 15 P age

16 subscribers can t be removed. This is done by using the input parameter EDI_SPEC_ID and querying the _LIB_SUBSCRIPTIONS table for a count of all records matching the given spec id. If the count is one or more, then the application reports the number of subscriptions to the user and states that it can t be deleted. If the count is zero, then the record can be safely removed and a final confirmation is provided to the user asking if the record should be deleted. Test Procedure 1. The module is tested by first navigating the CareLogic system to get to the EDI Library page. This is done by first logging in to the CareLogic system (image 1) and allowing the main screen to load (image 2). 2. Next, the Qualifacts tab was clicked followed by clicking on the EDI Library button (image 3). The system is now on the main search screen for the EDI Library (image 4). 3. To begin, a new record is added using the Add New EDI Record button found at the top right of the window (image 5). 4. Click both the Payer and Clearinghouse radio buttons to ensure that the form changes the required fields to fit the desired choice. 5. Pressing Submit returns to the search form with the newly created EDI type. 6. Within the search form, every and all combinations of search criteria are entered to do a comprehensive test of the search functionality. 16 P age

17 7. Once the search form is filled out, the Submit button is clicked and a new page loads that contains the restricted search results (image 6). 8. Within each listing, there are buttons to Select the record, Delete the record, the Specification of the EDI type, and Subscribers for the EDI type. The Select is the first button which is clicked (image 7). 9. To test this page, fill in more fields and then click the Submit buttons, effectively updating the record. 10. The restricted search results page is loaded again and the Delete button is then pressed. If the record has subscribers attached, an error appears (image 8), otherwise the page loads (image 9). 11. By selecting the Yes radio button and then clicking on the Submit button, the EDI record is deleted. This then returns to the restricted search results page. 12. Clicking the Specification button brings you to the EDI Specification page (image 10). This page will load with a summary of the information for the selected EDI type and the different levels within the EDI type. 13. Clicking the Return to EDI Library will bring the system back to the restricted search results page. 14. Next, click the Subscribers button which will load the EDI subscribers page (image 11). This page will show a listing of the clients currently subscribing to the EDI record. 17 P age

18 15. Begin by adding a subscriber using the Add Subscriber button found at the top right of the page. 16. This page loads add subscriber page (image 12), after bringing up the drop down menu, you are able to add any client that hasn t already been added as a subscriber to the EDI record. Once a subscriber is added, the system returns to the EDI subscribers page. Each listing has a Select and Delete button. 17. By clicking the Select button brings the user to the EDI Library Subscriptions page (image 13). This page shows the subscriptions to different EDI types that a client currently has open. 18. Clicking the Return to Subscribers button will return the system to the EDI subscribers page. 19. Clicking the Delete button allows the system to remove any subscriber from the EDI type (image 14). This completes the procedure for testing the full functionality of the design. Results Our design was implemented entirely within a test environment using a database with dummy data. The packages with the code to generate the CareLogic front end were the same as those used by Qualifacts customers. Therefore, the additions we made to the CareLogic application would work in a customer environment. We made a substantial effort to ensure that all 18 P age

19 possible situations for errors and inconsistencies were addressed in our code. This required envisioning all possible situations where a user might attempt or input something unexpected. We ended up modifying our code a great deal to accommodate for the large number of scenarios we came up with. The result was a very stable implementation in the test environment which impressed the Qualifacts staff. We were able to run many stress tests on our EDI library pages that succeeded in maintaining a stable visual interface for an end user. Our design was not implemented in an actual customer environment yet because it is part of a much larger project that Qualifacts has been working on. Conclusions The implementation of our EDI library management system seems like a fairly simple task, but there was a lot of work behind the scenes that cannot be understood by simply seeing a demonstration of the product. The majority of the time spent on this project was not on coding and implementing the library, but on understanding the operational concept and current system in place, then designing a product that met the requirements while maintaining compatibility with what was already in place. Our first major task was to understand the relationship between payers and health service providers and the process involved in an EDI transaction. Then, we had to familiarize ourselves with the CareLogic software front end and how it corresponded to back end code and database tables. This was the most difficult part because it required looking through thousands of lines of code and determining where information is coming from in the database. At this point we were finally able to come up with a basic design that would work along with the current system. Throughout the implementation 19 P age

20 our design, we had to learn an entirely new programming language, called PL/SQL, from which the pages in CareLogic are generated. Our design was modified and expanded to add new features several times throughout our implementation phase. Design changes are expected in any project, but we could have minimized them and saved ourselves time in the implementation phase by spending more time on the design phase of the project. The importance of a strong initial design is something that we have definitely learned through this project s entirety. The importance of communication became very evident during the implementation of our project design. At one point, the COO of Qualifacts was misinformed or uninformed of our progress on the implementation. The progress that we had presented to someone else in the company did not reach the COO or was misconstrued. As a result, the COO expressed concern to us about the completion of the project by the date agreed on. This is apparently a very common scenario in the real world. Fortunately, we had been following a strict schedule the entire time and were actually ahead of where we were supposed to be. The issue was eventually worked out and everyone was happy with the resulting product, though the incident served as a real eye opener to us. As software engineers, it is easier to forget about communicating our progress to others because we are not the ones that deal with the customers of a product. Those that deal directly with these customers are the ones held liable if the product is not delivered in time, and therefore it is important for them to be continually updated on progress of a product. Even if we know the product will be completed on time, we must make sure others on our team know as well. Good communication in a business environment is a necessity for success. 20 P age

21 Recommendations for Future Work Our project was part of a larger ongoing project that Qualifacts is working on. A useful addition to the project would be a routine for automating the update of customer databases with updated and new EDI specs based on our subscription library. Such an addition would run on a dedicated server and maintain connections with every customer database and respond to events such as new subscriptions being added by a customer. The new system would likely need a more thorough procedure for switching to updated EDI specs when they become effective, while continuing to use the old EDI spec until this point. This addition shouldn t require any modifications to the database structure since methods for managing payer EDI specs and subscribers to these specs are already in place. Automation can be dangerous if a piece of code encounters an error. We wouldn t want to end up deleting or overwriting important information if the automation process runs into a problem. For this reason, an automation process would need to have a thorough design as well as safety features like undoing database operations and reporting encounters with problems. These requirements make such an addition more exhaustive and time consuming than would seem. 21 P age

22 Appendiix A:: Data Sheets This is Appendix A from National Electronic Data Interchange Transaction Set Implementation Guide: 837 which details the complete effectuation of 837 EDI transactions (the most common standard for EDI transfers for health care services). The Appendix summarizes the important features and formatting rules for an 837 transaction. 22 P age

23 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL National Electronic Data Interchange Transaction Set Implementation Guide Health Care Claim: Professional 837 ASC X12N 837 (004010X098) May MAY 2000 Page 1

24 I ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL A ASC X12 Nomenclature A.1 A.1.1 Interchange and Application Control Structures Interchange Control Structure The transmission of data proceeds according to very strict format rules to ensure the integrity and maintain the efficiency of the interchange. Each business grouping of data is called a transaction set. For instance, a group of benefit enrollments sent from a sponsor to a payer is considered a transaction set. Each transaction set contains groups of logically related data in units called segments. For instance, the N4 segment used in the transaction set conveys the city, state, ZIP Code, and other geographic information. A transaction set contains multiple segments, so the addresses of the different parties, for example, can be conveyed from one computer to the other. An analogy would be that the transaction set is like a freight train; the segments are like the train's cars; and each segment can contain several data elements the same as a train car can hold multiple crates. The sequence of the elements within one segment is specified by the ASC X12 standard as well as the sequence of segments in the transaction set. In a more conventional computing environment, the segments would be equivalent to records, and the elements equivalent to fields. ISA GS ST SE ST SE GE GS ST SE GE IEA Communications Transport Protocol Interchange Control Header Functional Group Header Transaction Set Header Detail Segments for example, Benefit Enrollment Transaction Set Trailer Transaction Set Header Detail Segments for example, Benefit Enrollment Transaction Set Trailer Functional Group Trailer Functional Group Header Transaction Set Header Detail Segments for example, Claim Payment Transaction Set Trailer Functional Group Trailer Interchange Control Trailer Communications Transport Trailer GRO U P O NAL F UNCT U P F UNCT I O NAL GRO INT E RCHANG E ENVEL OPE O P E ENVEL CA T I ONS M M UNI CO Similar transaction sets, called "functional groups," can Figure A1. Transmission Control Schematic be sent together within a transmission. Each functional group is prefaced by a group start segment; and a functional group is terminated by a group end segment. One or more functional groups are prefaced by an interchange header and followed by an interchange trailer. Figure A1, Transmission Control Schematic, illustrates this interchange control. 24 P age MAY 2000 A.1

25 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE The interchange header and trailer segments envelop one or more functional groups or interchange-related control segments and perform the following functions: Define the data element separators and the data segment terminator. Identify the sender and receiver. Provide control information for the interchange. Allow for authorization and security information. A.1.2 A Application Control Structure Definitions and Concepts Basic Structure A data element corresponds to a data field in data processing terminology. The data element is the smallest named item in the ASC X12 standard. A data segment corresponds to a record in data processing terminology. The data segment begins with a segment ID and contains related data elements. A control segment has the same structure as a data segment; the distinction is in the use. The data segment is used primarily to convey user information, but the control segment is used primarily to convey control information and to group data segments. A Basic Character Set The section that follows is designed to have representation in the common character code schemes of EBCDIC, ASCII, and CCITT International Alphabet 5. The ASC X12 standards are graphic-character-oriented; therefore, common character encoding schemes other than those specified herein may be used as long as a common mapping is available. Because the graphic characters have an implied mapping across character code schemes, those bit patterns are not provided here. The basic character set of this standard, shown in figure A2, Basic Character Set, includes those selected from the uppercase letters, digits, space, and special characters as specified below. A...Z 0...9! " & ' ( ) * + -. / ' Figure A2. Basic Character Set : ;? = " " (space) A Extended Character Set An extended character set may be used by negotiation between the two parties and includes the lowercase letters and other special characters as specified in figure A3, Extended Character Set. a..z % [ ] _ { } \ Figure A3. Extended Character Set < > # Note that the extended characters include several character codes that have multiple graphical representations for a specific bit pattern. The complete list appears $ 25 P age A.2 MAY 2000

26 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL in other standards such as CCITT S.5. Use of the USA graphics for these codes presents no problem unless data is exchanged with an international partner. Other problems, such as the translation of item descriptions from English to French, arise when exchanging data with an international partner, but minimizing the use of codes with multiple graphics eliminates one of the more obvious problems. A Control Characters Two control character groups are specified; they have only restricted usage. The common notation for these groups is also provided, together with the character coding in three common alphabets. In the matrix A1, Base Control Set, the column IA5 represents CCITT V.3 International Alphabet 5. A Base Control Set The base control set includes those characters that will not have a disruptive effect on most communication protocols. These are represented by: NOTATION NAME EBCDIC ASCII IA5 BEL bell 2F HT LF VT FF CR FS GS RS US NL horizontal tab line feed vertical tab form feed carriage return file separator group separator record separator unit separator new line B 0C 0D 1C 1D 1E 1F A 0B 0C 0D 1C 1D 1E 1F 09 0A 0B 0C 0D 1C 1D 1E 1F Matrix A1. Base Control Set The Group Separator (GS) may be an exception in this set because it is used in the 3780 communications protocol to indicate blank space compression. A Extended Control Set The extended control set includes those that may have an effect on a transmission system. These are shown in matrix A2, Extended Control Set. NOTATION SOH NAME start of header EBCDIC 01 ASCII 01 IA5 01 STX start of text ETX end of text EOT end of transmission ENQ enquiry 2D ACK acknowledge 2E DC1 device control DC2 device control DC3 device control DC4 device control 4 3C NAK negative acknowledge 3D SYN synchronous idle ETB end of block Matrix A2. Extended Control Set 26 P age MAY 2000 A.3

27 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE A Delimiters A delimiter is a character used to separate two data elements (or subelements) or to terminate a segment. The delimiters are an integral part of the data. Delimiters are specified in the interchange header segment, ISA. The ISA segment is a 105 byte fixed length record. The data element separator is byte number 4; the component element separator is byte number 105; and the segment terminator is the byte that immediately follows the component element separator. Once specified in the interchange header, the delimiters are not to be used in a data element value elsewhere in the interchange. For consistency, this implementation guide uses the delimiters shown in matrix A3, Delimiters, in all examples of EDI transmissions. CHARACTER * : ~ Matrix A3. Delimiters NAME Asterisk Colon Tilde DELIMITER Data Element Separator Subelement Separator Segment Terminator The delimiters above are for illustration purposes only and are not specific recommendations or requirements. Users of this implementation guide should be aware that an application system may use some valid delimiter characters within the application data. Occurrences of delimiter characters in transmitted data within a data element can result in errors in translation programs. The existence of asterisks (*) within transmitted application data is a known issue that can affect translation software. A.1.3 Business Transaction Structure Definitions and Concepts The ASC X12 standards define commonly used business transactions (such as a health care claim) in a formal structure called "transaction sets." A transaction set is composed of a transaction set header control segment, one or more data segments, and a transaction set trailer control segment. Each segment is composed of the following: A unique segment ID One or more logically related data elements each preceded by a data element separator A segment terminator A Data Element The data element is the smallest named unit of information in the ASC X12 standard. Data elements are identified as either simple or component. A data element that occurs as an ordinally positioned member of a composite data structure is identified as a component data element. A data element that occurs in a segment outside the defined boundaries of a composite data structure is identified as a simple data element. The distinction between simple and component data elements is strictly a matter of context because a data element can be used in either capacity. 27 P age A.4 MAY 2000

28 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL Data elements are assigned a unique reference number. Each data element has a name, description, type, minimum length, and maximum length. For ID type data elements, this guide provides the applicable ASC X12 code values and their descriptions or references where the valid code list can be obtained. Each data element is assigned a minimum and maximum length. The length of the data element value is the number of character positions used except as noted for numeric, decimal, and binary elements. The data element types shown in matrix A4, Data Element Types, appear in this implementation guide. SYMBOL Nn R ID AN DT TM B TYPE Numeric Decimal Identifier String Date Time Binary Matrix A4. Data Element Types A Numeric A numeric data element is represented by one or more digits with an optional leading sign representing a value in the normal base of 10. The value of a numeric data element includes an implied decimal point. It is used when the position of the decimal point within the data is permanently fixed and is not to be transmitted with the data. This set of guides denotes the number of implied decimal positions. The representation for this data element type is "Nn" where N indicates that it is numeric and n indicates the number of decimal positions to the right of the implied decimal point. If n is 0, it need not appear in the specification; N is equivalent to N0. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) should not be transmitted. EXAMPLE A transmitted value of 1234, when specified as numeric type N2, represents a value of Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. The length of a numeric type data element does not include the optional sign. A Decimal A decimal data element may contain an explicit decimal point and is used for numeric values that have a varying number of decimal positions. This data element type is represented as "R." The decimal point always appears in the character stream if the decimal point is at any place other than the right end. If the value is an integer (decimal point at the right end) the decimal point should be omitted. For negative values, the leading minus sign (-) is used. Absence of a sign indicates a positive value. The plus sign (+) should not be transmitted. 28 P age MAY 2000 A.5

29 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE Leading zeros should be suppressed unless necessary to satisfy a minimum length requirement. Trailing zeros following the decimal point should be suppressed unless necessary to indicate precision. The use of triad separators (for example, the commas in 1,000,000) is expressly prohibited. The length of a decimal type data element does not include the optional leading sign or decimal point. EXAMPLE A transmitted value of represents a decimal value of A Identifier An identifier data element always contains a value from a predefined list of codes that is maintained by the ASC X12 Committee or some other body recognized by the Committee. Trailing spaces should be suppressed unless they are necessary to satisfy a minimum length. An identifier is always left justified. The representation for this data element type is "ID." A String A string data element is a sequence of any characters from the basic or extended character sets. The significant characters shall be left justified. Leading spaces, when they occur, are presumed to be significant characters. Trailing spaces should be suppressed unless they are necessary to satisfy a minimum length. The representation for this data element type is "AN." A Date A date data element is used to express the standard date in either YYMMDD or CCYYMMDD format in which CC is the first two digits of the calendar year, YY is the last two digits of the calendar year, MM is the month (01 to 12), and DD is the day in the month (01 to 31). The representation for this data element type is "DT." Users of this guide should note that all dates within transactions are 8-character dates (millennium compliant) in the format CCYYMMDD. The only date data element that is in format YYMMDD is the Interchange Date data element in the ISA segment, and also used in the TA1 Interchange Acknowledgment, where the century can be readily interpolated because of the nature of an interchange header. A Time A time data element is used to express the ISO standard time HHMMSSd..d format in which HH is the hour for a 24 hour clock (00 to 23), MM is the minute (00 to 59), SS is the second (00 to 59) and d..d is decimal seconds. The representation for this data element type is "TM." The length of the data element determines the format of the transmitted time. EXAMPLE Transmitted data elements of four characters denote HHMM. Transmitted data elements of six characters denote HHMMSS. A Composite Data Structure The composite data structure is an intermediate unit of information in a segment. Composite data structures are composed of one or more logically related simple data elements, each, except the last, followed by a sub-element separator. The final data element is followed by the next data element separator or the segment terminator. Each simple data element within a composite is called a component. 29 P age A.6 MAY 2000

30 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL Each composite data structure has a unique four-character identifier, a name, and a purpose. The identifier serves as a label for the composite. A composite data structure can be further defined through the use of syntax notes, semantic notes, and comments. Each component within the composite is further characterized by a reference designator and a condition designator. The reference designators and the condition designators are described below. A Data Segment The data segment is an intermediate unit of information in a transaction set. In the data stream, a data segment consists of a segment identifier, one or more composite data structures or simple data elements each preceded by a data element separator and succeeded by a segment terminator. Each data segment has a unique two- or three-character identifier, a name, and a purpose. The identifier serves as a label for the data segment. A segment can be further defined through the use of syntax notes, semantic notes, and comments. Each simple data element or composite data structure within the segment is further characterized by a reference designator and a condition designator. A Syntax Notes Syntax notes describe relational conditions among two or more data segment units within the same segment, or among two or more component data elements within the same composite data structure. For a complete description of the relational conditions, See A.1.3.8, Condition Designator. A Semantic Notes Simple data elements or composite data structures may be referenced by a semantic note within a particular segment. A semantic note provides important additional information regarding the intended meaning of a designated data element, particularly a generic type, in the context of its use within a specific data segment. Semantic notes may also define a relational condition among data elements in a segment based on the presence of a specific value (or one of a set of values) in one of the data elements. A Comments A segment comment provides additional information regarding the intended use of the segment. A Reference Designator Each simple data element or composite data structure in a segment is provided a structured code that indicates the segment in which it is used and the sequential position within the segment. The code is composed of the segment identifier followed by a two-digit number that defines the position of the simple data element or composite data structure in that segment. For purposes of creating reference designators, the composite data structure is viewed as the hierarchical equal of the simple data element. Each component data element in a composite data structure is identified by a suffix appended to the reference designator for the composite data structure of which it is a member. 30 MAY 2000 Page A.7

31 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE This suffix is a two-digit number, prefixed with a hyphen, that defines the position of the component data element in the composite data structure. EXAMPLE The first simple element of the CLP segment would be identified as CLP01. The first position in the SVC segment is occupied by a composite data structure that contains seven component data elements, the reference designator for the second component data element would be SVC A Condition Designator This section provides information about X12 standard conditions designators. It is provided so that users will have information about the general standard. Implementation guides may impose other conditions designators. See implementation guide section 3.1 Presentation Examples for detailed information about the implementation guide Industry Usage requirements for compliant implementation. Data element conditions are of three types: mandatory, optional, and relational. They define the circumstances under which a data element may be required to be present or not present in a particular segment. DESIGNATOR M- Mandatory O- Optional X- Relational DESCRIPTION The designation of mandatory is absolute in the sense that there is no dependency on other data elements. This designation may apply to either simple data elements or composite data structures. If the designation applies to a composite data structure, then at least one value of a component data element in that composite data structure shall be included in the data segment. The designation of optional means that there is no requirement for a simple data element or composite data structure to be present in the segment. The presence of a value for a simple data element or the presence of value for any of the component data elements of a composite data structure is at the option of the sender. Relational conditions may exist among two or more simple data elements within the same data segment based on the presence or absence of one of those data elements (presence means a data element must not be empty). Relational conditions are specified by a condition code (see table below) and the reference designators of the affected data elements. A data element may be subject to more than one relational condition. The definitions for each of the condition codes used within syntax notes are detailed below: CONDITION CODE P- Paired or Multiple R- Required E- Exclusion C- Conditional L- List DEFINITION If any element specified in the relational condition is present, then all of the elements specified must be present. At least one of the elements specified in the condition must be present. Not more than one of the elements specified in the condition may be present. If the first element specified in the condition is present, then all other elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment. 31 P age A.8 MAY 2000

32 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL Conditional If the first element specified in the condition is present, then at least one of the remaining elements must be present. However, any or all of the elements not specified as the first element in the condition may appear without requiring that the first element be present. The order of the elements in the condition does not have to be the same as the order of the data elements in the data segment. Table A5. Condition Designator A Absence of Data Any simple data element that is indicated as mandatory must not be empty if the segment is used. At least one component data element of a composite data structure that is indicated as mandatory must not be empty if the segment is used. Optional simple data elements and/or composite data structures and their preceding data element separators that are not needed should be omitted if they occur at the end of a segment. If they do not occur at the end of the segment, the simple data element values and/or composite data structure values may be omitted. Their absence is indicated by the occurrence of their preceding data element separators, in order to maintain the element's or structure's position as defined in the data segment. Likewise, when additional information is not necessary within a composite, the composite may be terminated by providing the appropriate data element separator or segment terminator. A Control Segments A control segment has the same structure as a data segment, but it is used for transferring control information rather than application information. A Loop Control Segments Loop control segments are used only to delineate bounded loops. Delineation of the loop shall consist of the loop header (LS segment) and the loop trailer (LE segment). The loop header defines the start of a structure that must contain one or more iterations of a loop of data segments and provides the loop identifier for this loop. The loop trailer defines the end of the structure. The LS segment appears only before the first occurrence of the loop, and the LE segment appears only after the last occurrence of the loop. Unbounded looping structures do not use loop control segments. A Transaction Set Control Segments The transaction set is delineated by the transaction set header (ST segment) and the transaction set trailer (SE segment). The transaction set header identifies the start and identifier of the transaction set. The transaction set trailer identifies the end of the transaction set and provides a count of the data segments, which includes the ST and SE segments. A Functional Group Control Segments The functional group is delineated by the functional group header (GS segment) and the functional group trailer (GE segment). The functional group header starts and identifies one or more related transaction sets and provides a control number 32 P age MAY 2000 A.9

33 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE and application identification information. The functional group trailer defines the end of the functional group of related transaction sets and provides a count of contained transaction sets. A Relations among Control Segments The control segment of this standard must have a nested relationship as is shown and annotated in this subsection. The letters preceding the control segment name are the segment identifier for that control segment. The indentation of segment identifiers shown below indicates the subordination among control segments. GS Functional Group Header, starts a group of related transaction sets. ST Transaction Set Header, starts a transaction set. LS Loop Header, starts a bounded loop of data segments but is not part of the loop. LS Loop Header, starts an inner, nested, bounded loop. LE Loop Trailer, ends an inner, nested bounded loop. LE Loop Trailer, ends a bounded loop of data segments but is not part of the loop. SE Transaction Set Trailer, ends a transaction set. GE Functional Group Trailer, ends a group of related transaction sets. More than one ST/SE pair, each representing a transaction set, may be used within one functional group. Also more than one LS/LE pair, each representing a bounded loop, may be used within one transaction set. A Transaction Set The transaction set is the smallest meaningful set of information exchanged between trading partners. The transaction set consists of a transaction set header segment, one or more data segments in a specified order, and a transaction set trailer segment. See figure A1, Transmission Control Schematic. A Transaction Set Header and Trailer A transaction set identifier uniquely identifies a transaction set. This identifier is the first data element of the Transaction Set Header Segment (ST). A user assigned transaction set control number in the header must match the control number in the Trailer Segment (SE) for any given transaction set. The value for the number of included segments in the SE segment is the total number of segments in the transaction set, including the ST and SE segments. A Data Segment Groups The data segments in a transaction set may be repeated as individual data segments or as unbounded or bounded loops. A Repeated Occurrences of Single Data Segments When a single data segment is allowed to be repeated, it may have a specified maximum number of occurrences defined at each specified position within a given transaction set standard. Alternatively, a segment may be allowed to repeat 33 P age A.10 MAY 2000

34 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL an unlimited number of times. The notation for an unlimited number of repetitions is ">1." A Loops of Data Segments Loops are groups of semantically related segments. Data segment loops may be unbounded or bounded. A Unbounded Loops To establish the iteration of a loop, the first data segment in the loop must appear once and only once in each iteration. Loops may have a specified maximum number of repetitions. Alternatively, the loop may be specified as having an unlimited number of iterations. The notation for an unlimited number of repetitions is ">1." A specified sequence of segments is in the loop. Loops themselves are optional or mandatory. The requirement designator of the beginning segment of a loop indicates whether at least one occurrence of the loop is required. Each appearance of the beginning segment defines an occurrence of the loop. The requirement designator of any segment within the loop after the beginning segment applies to that segment for each occurrence of the loop. If there is a mandatory requirement designator for any data segment within the loop after the beginning segment, that data segment is mandatory for each occurrence of the loop. If the loop is optional, the mandatory segment only occurs if the loop occurs. A Bounded Loops The characteristics of unbounded loops described previously also apply to bounded loops. In addition, bounded loops require a Loop Start Segment (LS) to appear before the first occurrence and a Loop End Segment (LE) to appear after the last occurrence of the loop. If the loop does not occur, the LS and LE segments are suppressed. A Data Segments in a Transaction Set When data segments are combined to form a transaction set, three characteristics are applied to each data segment: a requirement designator, a position in the transaction set, and a maximum occurrence. A Data Segment Requirement Designators A data segment, or loop, has one of the following requirement designators for health care and insurance transaction sets, indicating its appearance in the data stream of a transmission. These requirement designators are represented by a single character code. DESIGNATOR M- Mandatory O- Optional DESCRIPTION This data segment must be included in the transaction set. (Note that a data segment may be mandatory in a loop of data segments, but the loop itself is optional if the beginning segment of the loop is designated as optional.) The presence of this data segment is the option of the sending party. A Data Segment Position The ordinal positions of the segments in a transaction set are explicitly specified for that transaction. Subject to the flexibility provided by the optional requirement designators of the segments, this positioning must be maintained. 34 P age MAY 2000 A.11

35 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE A Data Segment Occurrence A data segment may have a maximum occurrence of one, a finite number greater than one, or an unlimited number indicated by ">1." A Functional Group A functional group is a group of similar transaction sets that is bounded by a functional group header segment and a functional group trailer segment. The functional identifier defines the group of transactions that may be included within the functional group. The value for the functional group control number in the header and trailer control segments must be identical for any given group. The value for the number of included transaction sets is the total number of transaction sets in the group. See figure A1, Transmission Control Schematic. A.1.4 A Envelopes and Control Structures Interchange Control Structures Typically, the term "interchange" connotes the ISA/IEA envelope that is transmitted between trading/business partners. Interchange control is achieved through several "control" components. The interchange control number is contained in data element ISA13 of the ISA segment. The identical control number must also occur in data element 02 of the IEA segment. Most commercial translation software products will verify that these two fields are identical. In most translation software products, if these fields are different the interchange will be "suspended" in error. There are many other features of the ISA segment that are used for control meas- ures. For instance, the ISA segment contains data elements such as authorization information, security information, sender identification, and receiver identification that can be used for control purposes. These data elements are agreed upon by the trading partners prior to transmission and are contained in the written trading partner agreement. The interchange date and time data elements as well as the interchange control number within the ISA segment are used for debugging purposes when there is a problem with the transmission or the interchange. Data Element ISA12, Interchange Control Version Number, indicates the version of the ISA/IEA envelope. The ISA12 does not indicate the version of the transaction set that is being transmitted but rather the envelope that encapsulates the transaction. An Interchange Acknowledgment can be denoted through data element ISA14. The acknowledgment that would be sent in reply to a "yes" condition in data element ISA14 would be the TA1 segment. Data element ISA15, Test Indicator, is used between trading partners to indicate that the transmission is in a "test" or "production" mode. This becomes significant when the production phase of the project is to commence. Data element ISA16, Subelement Separator, is used by the translator for interpretation of composite data elements. The ending component of the interchange or ISA/IEA envelope is the IEA segment. Data element IEA01 indicates the number of functional groups that are included within the interchange. In most commercial translation software products, an aggregate count of functional groups is kept while interpreting the interchange. This count is then verified with data element IEA01. If there is a discrep- 35 P age A.12 MAY 2000

36 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL ancy, in most commercial products, the interchange is suspended. The other data element in the IEA segment is IEA02 which is referenced above. See the Appendix B, EDI Control Directory, for a complete detailing of the interchange control header and trailer. A Functional Groups Control structures within the functional group envelope include the functional identifier code in GS01. The Functional Identifier Code is used by the commercial translation software during interpretation of the interchange to determine the different transaction sets that may be included within the functional group. If an inappropriate transaction set is contained within the functional group, most commercial translation software will suspend the functional group within the interchange. The Application Sender's Code in GS02 can be used to identify the sending unit of the transmission. The Application Receiver's Code in GS03 can be used to identify the receiving unit of the transmission. For health care, this unit identification can be used to differentiate between managed care, indemnity, and Medicare. The functional group contains a creation date (GS04) and creation time (GS05) for the functional group. The Group Control Number is contained in GS06. These data elements (GS04, GS05, AND GS06) can be used for debugging purposes during problem resolution. GS08,Version/Release/Industry Identifier Code is the version/release/sub-release of the transaction sets being transmitted in this functional group. Appendix B provides guidance for the value for this data element. The GS08 does not represent the version of the interchange (ISA/IEA) envelope but rather the version/release/sub-release of the transaction sets that are encompassed within the GS/GE envelope. The Functional Group Control Number in GS06 must be identical to data element 02 of the GE segment. Data element GE01 indicates the number of transaction sets within the functional group. In most commercial translation software products, an aggregate count of the transaction sets is kept while interpreting the functional group. This count is then verified with data element GE01. See the Appendix B, EDI Control Directory, for a complete detailing of the functional group header and trailer. A HL Structures The HL segment is used in several X12 transaction sets to identify levels of detail information using a hierarchical structure, such as relating dependents to a subscriber. Hierarchical levels may differ from guide to guide. The following diagram, from transaction set 837, illustrates a typical hierarchy. Dependents Subscribers Provider Each provider can bill for one or more subscribers, each subscriber can have one or more dependents and the subscriber and the dependents can make one or more claims. Each guide states what levels are available, the level's requirement, a repeat value, and whether that level has subordinate levels within a transmission. 36 P age MAY 2000 A.13

37 004010X HEALTH CARE CLAIM: PROFESSIONAL ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE A.1.5 A Acknowledgments Interchange Acknowledgment, TA1 The Interchange or TA1 Acknowledgment is a means of replying to an interchange or transmission that has been sent. The TA1 verifies the envelopes only. Transaction set-specific verification is accomplished through use of the Functional Acknowledgment Transaction Set, 997. See A.1.5.2, Functional Acknowledgment, 997, for more details. The TA1 is a single segment and is unique in the sense that this single segment is transmitted without the GS/GE envelope structures. A TA1 can be included in an interchange with other functional groups and transactions. Encompassed in the TA1 are the interchange control number, interchange date and time, interchange acknowledgment code, and the interchange note code. The interchange control number, interchange date and time are identical to those that were present in the transmitted interchange from the sending trading partner. This provides the capability to associate the TA1 with the transmitted interchange. TA104, Interchange Acknowledgment Code, indicates the status of the interchange control structure. This data element stipulates whether the transmitted interchange was accepted with no errors, accepted with errors, or rejected because of errors. TA105, Interchange Note Code, is a numerical code that indicates the error found while processing the interchange control structure. Values for this data element indicate whether the error occurred at the interchange or functional group envelope. The TA1 segment provides the capability for the receiving trading partner to notify the sending trading partner of problems that were encountered in the interchange control structure. Due to the uniqueness of the TA1, implementation should be predicated upon the ability for the sending and receiving trading partners commercial translators to accommodate the uniqueness of the TA1. Unless named as mandatory in the Federal Rules implementing HIPAA, use of the TA1, although urged by the authors, is not mandated. See the Appendix B, EDI Control Directory, for a complete detailing of the TA1 segment. A Functional Acknowledgment, 997 The Functional Acknowledgment Transaction Set, 997, has been designed to allow trading partners to establish a comprehensive control function as a part of their business exchange process. This acknowledgment process facilitates control of EDI. There is a one-to-one correspondence between a 997 and a functional group. Segments within the 997 can identify the acceptance or rejection of the functional group, transaction sets or segments. Data elements in error can also be identified. There are many EDI implementations that have incorporated the acknowledgment process in all of their electronic communications. Typically, the 997 is used as a functional acknowledgment to a previously transmitted functional group. Many commercially available translators can automatically generate this transaction set through internal parameter settings. Additionally translators will automatically reconcile received acknowledgments to functional groups that have been sent. The benefit to this process is that the sending trading partner 37 P age A.14 MAY 2000

38 ASC X12N INSURANCE SUBCOMMITTEE IMPLEMENTATION GUIDE X HEALTH CARE CLAIM: PROFESSIONAL can determine if the receiving trading partner has received ASC X12 transaction sets through reports that can be generated by the translation software to identify transmissions that have not been acknowledged. As stated previously the 997 is a transaction set and thus is encapsulated within the interchange control structure (envelopes) for transmission. As with any information flow, an acknowledgment process is essential. If an "auto- matic" acknowledgment process is desired between trading partners then it is recommended that the 997 be used. Unless named as mandatory in the Federal Rules implementing HIPAA, use of the 997, although recommended by the authors, is not mandated. See Appendix B, EDI Control Directory, for a complete detailing of transaction set 997. MAY 2000 A.15

39 EDI Library Appendiix B:: User s Manuall CareLogic Web Application Getting Started... Error! Bookmark not defined. Logging into the System... Error! Bookmark not defined. EDI Library Records... Error! Bookmark not defined. Searching for Records... Error! Bookmark not defined. Selecting Records... Error! Bookmark not defined. Adding Records... Error! Bookmark not defined. Deleting Records... Error! Bookmark not defined. EDI Subscriptions... Error! Bookmark not defined. Seleting Subscribers... Error! Bookmark not defined. Adding Subscribers... Error! Bookmark not defined. Deleting Subscribers... Error! Bookmark not defined. EDI Specifications... Error! Bookmark not defined. Editing EDI Type Information... Error! Bookmark not defined. Adding/Editing Levels... Error! Bookmark not defined. Adding/Removing/Editing Level Segments... Error! Bookmark not defined. 39

40 Getting Started Logging into the System: If you are a first time user to the system, the first thing you need to know is that CareLogic is a web based application that can only be used in Internet Explorer. You will not be able to log into the system via any other internet browser. (NOTE: Some browsers, such as Mozilla Firefox, have the capability to run Internet Explorer as a plug in; this alternative will work if you do not want to install and use the actual Internet Explorer application.) To reach the CareLogic application, you must type the following into the browser address bar: After typing in the address and pressing enter, IE (Internet Explorer) should take you to the CareLogic homepage (Figure 1). Figure 1 Here, you must type in the login information that was given to you by Qualifacts and then click the Submit button. You will arrive at the main page of the CareLogic system (Figure 2) and now need to navigate to the EDI Library section of CareLogic. This can be done by first clicking the Qualifacts button located on the toolbar at the top of the webpage. This button is situated between the Administration and Billing/ AR buttons. 40

41 Figure 2 Once you click the Qualifacts button, a blank page will appear but now there is a second toolbar located beneath the original toolbar (Figure 3). This toolbar contains the button which links to the EDI Library which is appropriate labeled EDI Library. It is the last button on the toolbar. After clicking this button you will be at the EDI Library s main page (Figure 4). Figure 3 41

42 Figure 4 42

43 EDI Library Records Searching for Records: On the main page of the EDI Library, you will see the search form and a list of all the records that are currently in the CareLogic database. Here you will be able to search through the list of records by Effective Date, End Date, Payer/Clearinghouse, State, Payer Plan, County, and EDI Type. If you leave the fields blank and click the submit button, which is in the top right section of the page, the system will just return all of the records that are in the database listed by the most recent effective date. Selecting Records: On the left each of the records that appear on the main page are four buttons: Select, Delete, Specification, and Subscribers. Clicking the Select button will bring you to the page that contains the information for that EDI Library Record (Figure 5). Here you can change the different properties of an EDI Record. Figure 5 Adding Records: A record may be added to the database at any time by returning to the main search form (Figure 4) and clicking on the Add New EDI Record button located at the top right section of the webpage. (NOTE: You can return to the main page at anytime from any of the other EDI Library pages by clicking the Return to EDI Library button at the top right section of the webpage. This button may have a different name on some pages but it serves the same function.) After clicking on the Add New EDI Record button, you will be taken to a new page. This page looks exactly the same as the Select Record page and has the same fields (Figure 5). The only difference is that upon clicking the Submit button, a completely new record will be added to the database instead of editing one that already exists. (NOTE: The fields that are shaded red are required fields that need to have something in them in order to submit the form. Also, the fields that are required for a Payer are not the same as the fields that are required for a Clearinghouse.) 43

44 Deleting Records: A record may be deleted from the database at any time by returning to the main search form once again (Figure 4) and clicking the Delete button which is located in the four button group on the left of every record. Once the button is pressed you will be taken to another page that will ask for confirmation (Figure 6). Here you can either select whether or not you want to delete the record using the Yes or No options and then clicking submit. You can also cancel the action and return to the main search form using the Cancel and Return button located at the top right section of the page. (NOTE: Only records that do not have any subscribers can be deleted. If a record has any subscribers then an error message will appear in a tool bar once the button is pressed (Figure 7).) Figure 6 Figure 7 44

45 EDI Subscriptions In order to see what organizations are subscribed to an EDI specification in a record, you must click the Subscribers button located in the four button group on the left of any record on the main search form. Clicking this button takes you to a new screen that shows information about the current record and lists the subscribers to the EDI specification (Figure 8). The list shows the subscribers name and the date on which they started their subscription. Figure 8 Selecting Subscribers: You may select a subscriber by clicking the Select button which is the leftmost button next to each subscriber name. This button will take you to a new page that contains all the information of that particular subscriber (Figure 9). This page only contains the organizations information and cannot be edited. You can also see information about the record that you are currently accessing below the subscriber information. After reviewing the subscriber s information you may return to the original list by clicking the Return to Subscribers button located in the top right section of the screen. 45

46 Figure 9 Adding Subscribers: A subscriber may be added to an EDI specification at any time by clicking on the Add subscriber button located at the top right section of the main subscriber screen (Figure 8). After clicking on the Add Subscriber button, you will be taken to a new page. This page contains information about the record currently being viewed and has a drop down menu with a list of organizations (Figure 10). You may use the drop down menu to choose an organization that you want to add to the current EDI specification. After choosing one, pressing the Submit button will add the organization and return you to the original subscribers page. You may only add one organization at a time. (NOTE: The drop down menu will only contain organizations that are NOT currently subscribed to the EDI specification. If you do not see an organization in the menu that should be there, it may be because that it has already been used.) 46

47 Figure 10 Deleting Subscribers: A subscriber may be deleted from an EDI specification at any time by clicking the Delete button on the right of the Select button next to each subscriber name. After pressing the button, you will be taken to another page that will ask for confirmation (Figure 11). Here you can either select whether or not you want to delete the subscriber from the EDI specification using the Yes or No options and then clicking submit. You can also cancel the action and return to the main subscribers page using the Cancel and Return button located at the top right section of the page. Figure 11 47

48 EDI Specifications In order to see and edit a records EDI specification, you must click the Specification button located in the four button group on the left of any record on the main search form. Clicking this button takes you to a new screen that shows information about the current record and the levels that its EDI specification contains (Figure 12). Figure 12 Editing EDI Type Information: You can edit the EDI type information by clicking on the Edit EDI Type Info button located in the top right section of the screen. This button will take you to another page that allows you to edit all the information for that EDI specification (Figure 13). If you wish to change any of the information, you may do so then click the submit button to apply all changes made and the page will automatically be refreshed. From here, you can also go to the EDI Type List which holds all the current EDI types by clicking the Return to EDI Type List button (Figure 14). You may edit the current edit types or create new ones on this page. 48

49 Figure 13 Figure 14 Adding/Editing Levels: You may add and edit levels to an EDI specification by clicking the Add Levels button on the EDI Type Info page (Figure 13) or by clicking the Add/Edit Levels button on the main EDI specification page (Figure 12). Both of these buttons are located in the top right section of the pages that they are on. The buttons take you to a new page where you can either edit the current levels for the EDI specification or add new ones (Figure 15). Once you make a change or add a new level, you must click the submit button for all changes to be applied and the page will automatically be refreshed. 49

50 Figure 15 Adding/Removing/Editing Level Segments: You may add or remove a level segment by clicking on the Add button located under the Add/Remove Segments column on the main EDI specification page (Figure 12). This button will take you to another page where there is a list of all the current segments in that particular level of the EDI specification (Figure 16). To add a segment you must check the box for the type of segment you want then choose submit. Figure 16 50

51 Once you click submit, a new page will open where you can add code to the segment you just created (Figure 17). This page is the Edit Segment page. To remove a segment, you must first return to the Add segment page and then uncheck the box next to a segment you want to remove. (NOTE: If the box next to segment you wish to remove is not checked, then this EDI specification level does not have that segment in it.) Figure 17 51

52 Appendiix C:: Drawiings and Diiagrams This is an ER (entity relationship) Diagram showing the tables we implemented into the database as well as their relationship to each other and the existing tables in the CareLogic back end database. 52

53 This diagram shows the visual flow of the web pages associated with the EDI library. It indicates which pages can be reached from each other page. 53

54 Appendiix D:: Customer Contact Infformatiion Lyn Gives/Brad Bills Qualifacts Systems Inc nd Ave. South Nashville, TN (615)

55 Appendiix E:: Siimullatiion Resullts Image 1 Image 2 55

56 Image 3 Image 4 56

57 Image 5 Image 6 57

58 Image 7 Image 8 58

59 Image 9 Image 10 59

60 Image 11 Image 12 60