Rules for processing X12 transaction files are stored in the following rulesets:

• PegaX12 — Base classes for all supported X12 messages
• PegaX125010 — Rules for processing version 5010 of the X12 EDI Standard
• PegaHCEDI —Rules and sample business processes for processing 270/271 and 276/277 transactions

There is a class for each segment in the X12 standard and a property for each data element in the segment. These classes are common to all transaction types and can be used by each of them. In addition, a class exists for each transaction type (such as PegaX12-Data-N837), which is built using the predefined classes as the inbound X12 message file is processed.

The data in an X12 message is typically received by a File or MQ Listener agent rule that maps the data to properties on the clipboard. An activity rule dynamically determines the message type based on information in the functional group segment of the message. A clipboard page is created that includes all the transactions that are found in the functional group. It is assumed that a functional group contains transactions of the same type (e.g. all 837). However, an X12 message file can contain more than one functional group, and each group can contain different transaction types. While unlikely, Pega Foundation for Healthcare can process an X12 message file containing multiple transaction types and map them all to the clipboard. Pega Foundation for Healthcare maps the data in the message to the X12 clipboard page. The following example is for the N837 claim transaction:

• While maintaining the looping structure, a property of an associated class is created for each segment as embedded pages in the PegaX12-Data-N837 class.
• Properties are then created in each of these segment classes for each data element.
• These segment classes are defined in the PegaX12-Data- class and are general for all message types.
• A class is created for each loop.