American National Standards Institute electronic medical claims are not rocket science, they are specially formatted text files designed to convey claim information in a manner sufficient to allow claim adjudication. That being said there has been some anecdotal evidence that the standards were invented by the devil. On the contrary, the standards simply originated prior to the advent of what we now call high-speed data communications. In the late seventies and early eighties, phone lines equivalent to cable modems or DSL lines were available for many thousands of dollars per month. The standards were designed with a couple of very basic assumptions, which if remembered, help to erase some of the confusion.

ANSI standards for electronic data interchange, EDI, are designed to minimize the number of characters transmitted from one computer to another. If we also understand that blank spaces are represented in computers by codes that take the same physical memory space as any other character, we begin to see the logic of ANSI. We need also remember that the standards were designed by committees of interested parties who were able to travel to nice hotels on company time. The interests of the payer community were well represented; those of the providers were not. Consequently, the standards contain provisions for adjudication of even the most arcane possible claims. They also contain provisions for governmental programs, read Medicare, which are not applicable to many other payment scenarios.

Another thing the standards have not done well historically is to understand managed care. Since the people designing the standards regarded the folks from managed care organizations as lepers trespassing on their turf, provisions for some features of managed care, like networks, were not handled well in early versions of the standards. One last and important item is version independence. Each version of the ANSI standards is completely independent from earlier versions. Unlike the National Standard formats published by HCFA which has always been upward compatible, ANSI makes no pretension about version compatibility. This means that each new version could require brand new software to make it work. With this in mind and remembering that a camel is a horse designed by a committee we move on to trying to understand the ANSI medical claim files.

An ANSI message is said to start at the beginning and end at the end. There are no provisions in ANSI standards to make messages readable by humans. What this really means is that there are no spaces, carriage returns or line feeds in the messages. When viewed with a standard text editor one sees a single long string of characters on a single line. If you open an ANSI message file with some text editors, notably WordPad or Word, the text editors automatically insert line wrapping to aid in readability. When one closes the file and answers the inevitable question, “Do You Wish to Save Changes?” The innocuous answer of yes just rendered your file useless. There are some text editors available which will not automatically screw up your file. A good one, Edituer, is shareware and available on the web.

Instead of the type of spacing we are used to in documents read by humans, ANSI messages are delimited. This means that there are certain characters which are assigned special meaning within a specific message. The tilde character, ~, in the upper left position of most keyboards, takes the place of a carriage return / line feed. The asterisk character separates data elements and the colon separates sub elements. What, you ask, are segments, data elements and sub-elements? Since you are now novices on your quest for membership in the priesthood you will need to understand these terms. A segment is analogous to a record in data processing. A data element is analogous to a field and a sub-element is analogous to a field, which is an array. Examples of a segment are the last line of an address, city, state and zip code. You will notice that segments are composed of one or more data elements or sub-elements. Data elements are defined in a data dictionary promulgated as part of the standard. In the above example of a segment, the city name is data element number 19. It is an alphanumeric string, which is a minimum of two characters long, and a maximum of thirty characters long. Any time we have a message definition, which includes data element 19, we know that it is a city name. Data elements may be of several types, alpha, numeric, decimal, date, time or identifiers, id numbers. The segment comprised of city, state and zip code is defined as an N4 segment. It is defined in the standard as being made up of up to six data elements, city name, state code, postal code, country code, location qualifier, location identifier. These data elements must be listed in order, if they exist, or placeholders inserted in their absence. Any missing data at the end of the segment is simply ignored. Any time we see the nomenclature N4 in a specification we know it to be the last address line, containing city, state, zip etc. example:

N4*LITTLE ROCK*AR*54321~

Note that the space character has not been removed from within the data element “Little Rock” but the spaces between the city name, state and zip have replaced with data element delimiters, “*”. The carriage return and line feed have been replaced with the tilde character.

Groups of segments are assembled together to create meaningful messages. An individual’s name may be one segment, their address another and city state and zip a third. A group of segments in a particular order define a Transaction Set. In ANSI X12 version 4 release 10, a.k.a. X12 4010 the transaction set number 837 is defined as a medical claim. Its structure is designed to be all things to all people with regard to medical claims. It contains structure for professional claims, institutional claims and dental claims all in one specification. Remember the OSHA cowboy? The technique used to differentiate between professional, institutional and dental claims is what is called an implementation guide. The implementation guide is what takes the ANSI specification from a loose sort of format to a definition of a specific application between to unrelated entities, called Trading Partners. Repeat: specificity comes from an implementation guide. Absent an implementation guide we are talking only in generalities and jargon from trade publications, designed to confuse and obfuscate. Computers are not good with generalities. A collection of similar transaction sets is called a Functional Group. A collection of functional groups comprise a message or Data Interchange. An ANSI message may contain any number of functional groups and functional groups may contain any number of like transaction sets. The limits are defined in the implementation guide. The only requirement is that the message be composed of information, which is to be transmitted to the next immediate recipient. You can bunch together lots of claims to be sent to a clearinghouse and the clearinghouse may then repackage the claims into messages for particular payers. A message may contain transaction sets, which are eligibility inquiries, claim status inquiries, and claims. Similarly a response to this message from the trading partner may contain transaction sets, which represent claim payments, eligibility inquiry responses and claim status inquiry responses. All of this functionality in one long line! No wonder nobody made the deadline for implementation.

ANSI X12 messages are designed to model paper forms. We can think of inter-office mail in the old brown envelopes with holes punched in them so we could see if they were empty or not. Inside the inter-office envelope just received by a branch department, there could be a several number 10 envelopes, each of which contained different forms. Each number 10 envelope could contain several like forms, such as paychecks. The brown envelope is a message, the number 10 envelopes are functional groups and the paychecks are transaction sets. Some of the other number 10 envelopes could contain other transaction sets, such as invitations to the company picnic. Within ANSI EDI the envelopes are represented by what are known as control segments. They contain data about the message, not data about a transaction. Data about data is called metadata. In the ANSI priesthood these are known as interchange control segments.

The first segment in any ANSI message is called the ISA segment, which stands for interchange start. The last segment in an ANSI message is called the IEA segment, which stands for interchange end. Some of the rules for the message are defined in the ISA segment. It contains the id number for the message assigned by the submitter, the identification number of the submitter, the intended recipient id and what delimiters will be used. The ISA segment is the only fixed length segment in all of ANSI X12. Like transaction sets are grouped together in functional groups bounded at the beginning by a GS or Group Start, segment and trailed by a GE or Group End segment. Each transaction set begins with an ST or transaction start segment. The end of the transaction set is determined by the start of the next transaction set or a group or interchange end segment. Where you ask is the transaction set end statement? Remember what we said early on about minimizing the amount of data transmitted? It is not mathematically necessary, so it’s toast.

Repeated instances of a transaction set are called loops. The structure of the message loops back to the beginning and repeats itself. There are looping structures within each transaction set for medical claims as well. Claim detail lines, SV1 segments for professional claims, may repeat up to the number of times indicated in the implementation guide, usually up to 50 or 100 times as opposed to the six or 12 lines on a paper form. There may be several claims for a particular individual within a transaction set. This too is handled by a looping structure. The same group of segments repeats itself although containing different data each time. A particular loop may be bounded by a loop start and loop end segments or not depending on the uniqueness of segment types within a looping structure. That is, if we can determine a loop end without a loop end segment, but by a data element, which starts another repeating or subsequent segment we do not need a loop start or loop end segment. There is a looping structure for batches of claims from the same billing entity or billing provider. Within the implementation guides, proper formatting of the looping structure definition helps readability of transaction set structure. This is usually done by indentation on the left and the correct number of vertical lines on the right indicating the depth of the looping structure.

We hope that this primer has been instructive. If it has left you with a burning desire to write lots of computer programs yourself, we wish you well. If not, give us a call.

Empire Medical Review Services, Inc
11357 North Port Washington Road
Phone: 262.240.9700
Mequon, Wisconsin 53092