Tables are not regarded as HL7 objects as was described above (see section General concept), since tables are not exchanged during transactions. Rather tables provide means to interpret ID data fields correctly. They are merely classes with an enum type which is a mapping from symbolic names to integers, and a static array, which provides the mapping from the integers to character strings. Finally some useful member functions are provided which look up the item number of an ID in the table of character strings or translate such a number back to an ID. Even though these table objects are simple, it seems reasonable to enhance them to interface a data base management system for bigger tables as are classifications and other coding systems.
Some identifiers used by HL7 are listed in a HL7 table. Notably the message type identifiers. But there are others, such as segment and data type identifiers, which are not listed in such a table. It would be of some use for implementations to have these tables. Rather than keeping distict tables for the implementation of the protocol and the application using the protocol, there should be only one set of tables which are uniformly used by both. Thus we will generate entries in the `Table' and `Table Value' relation which list segment and type identifiers. To avoid conflicts with table numbers we will count down from the highest possible number (i.e. 9999 for tables and 999999 for values).