Code Definitions

A code definition lets the application know what provider, diagnosis and services codes look like, but can also specify other code systems such as a code field specific to the local EDI standards. Part of the code definition is the list of allowable codes.

Suppose a configurator extends the claim line table with a 'place of service' field. This field is part of a nation wide standard and has a predefined domain of values. The payer needs these codes to be represented in OHI Claims Adjudication and Pricing. The way to set that up is to create a code definition that specifies all the allowed codes and subsequently create a dynamic field usage based on that definition.

A code definition is essentially a composite of field definitions described in the previous chapter. The codes that belong to a flex code definition are predefined in the application. Whenever the application encounters a code for the given definition, it matches it against the allowed domain; if it can’t be found the code is not accepted which leads to the rejection of a claim or the inability to save the code in the user interface.

Flex Code Definitions

Consider the following image. It shows the configuration breakdown of a flex code definition and its flex codes. Flex codes are values that represent a domain. The purpose of such a domain is to bound the values of a dynamic field. A flex code is not (necessarily) a single value, that is, commonly a flex code is a record of several fields, each field with its own value. For example, a flex code can consist of a code and description field, as shown in the figure below. In this sense, a flex code definition is very similar to a table definition. The columns of the table are defined by flex code field usages. A flex code always keeps track of a start and end date, and the definition to which it belongs.

Note that the image reflects the setup for a flex code system that is used to specify a dynamic field. On the other hand, flex code systems that are used to specify procedure, diagnosis and provider codes do not have flex codes as values. Instead, these flex code systems are populated by the actual records in the procedure, diagnosis and provider tables.

Definition

A flex code definition is simply an umbrella under which the pertaining details are persisted that further specify the definition.

Field	Description
Code	The identifying code of flex code definition
Description	A description of this flex code definition

A flex code definition has one or more flex code field usages. Each flex code field usage represents a column in a flex code. Flex code field usages have the following attributes:

Field	Description
Name	The unique name of the column (within the a code) in the object model
Display name	The column header when the codes are shown in a table view
Display sequence	The column position when the codes are shown in a table view
Field	The data type, length, decimals and other validations that apply
Key?	If checked, then this field is the flex code key field.
Descriptor?	If checked, then this field is the flex code description field.
Mandatory?	If checked, then this field is mandatory for each flex code.
Allowable values	References another flex code definition. The value of this field must be one of the available key field values of the referenced definition.

To clarify the purpose of the listed attributes consider the following scenario:

A payer wants to extend claim lines on professional claims with a field that captures the 'place of service' attribute. The payer intends to use a flex code system for this dynamic field. The payer sets up the following flex code definition:

• Code: POS

• Description: Place of service on professional claims

For each possible place of service, the payer stores two fields: the key, which is a two digit code, and a description, which is a 60 character field. For this purpose, the payer creates two flex fields:

• Code: D2, Data type: char, Length: 2, condition: ONLY DIGITS

• Code: C60, Data type: char, Length: 60

The condition ONLY DIGITS is a condition dynamic logic that enforces that only characters 0 through 9 are allowed. The reason why this field is specified as a character field rather than a number field is that only character fields are allowed to be used as flex code key fields. The last step is to specify the flex code fields, connecting the flex code definition with the flex fields. The payer creates the following two flex code field usages for the POS flex code definition:

• Code: "pos", Display name: "PoS", Display sequence:0, Flex field:D2, Key?: checked, Mandatory?: checked.

• Code: "description", Display name: "Description", Display sequence:1, Flex field:C60, Description?: checked, Mandatory?: checked.

The payer has now set up a complete definition. The next step is to setup the allowed values within this definition, that is, the flex codes. The following rules apply to flex code field usages within the context one flex code definition:

• Only one field usage can represent the key field.

• Only one field usage can represent the descriptor field.

• The key field is always mandatory.

• The key field is always the first field that is displayed (display sequence 0).

• The descriptor field is always the second field that is displayed (display sequence 1).

• Alphanumeric fields (including the key field) can be up to 1000 characters long.

• Once flex codes exist for a definition, only the display sequence and the display name may be updated.

• Once flex codes exist for a definition, it is no longer allowed to create new key and/or descriptor fields.

• The flex field that represents the key field must be of the character data type.

• The 'allowable values' attribute may only be set for non-key, non-descriptor fields.

Values

Flex codes represent the actual values that belong to a flex code definition. This entity has no fixed set of attributes, that is, the attribute fields are defined by the flex code definition.

A flex code always has a start and end date. The start and end date represent the period in which the flex code is a valid value within the domain set out by the flex code definition. It is not allowed for two flex codes within the same flex code definition to have the same key field value at any one point in time.

Flex Code Set

A flex code set is a group of flex code definitions.

Field	Description
Code	The identifying code of flex code definition
Description	A description of this flex code definition
List of code definitions	The code definitions that belong tho this set

It is possible for a dynamic field to refer to a flex code set, rather than a flex code definition. If this is the case, then any flex code of any of the definitions under that set is an allowed value for that dynamic field.

Procedure and diagnosis codes are always defined by a flex code set, because the common case is that multiple standards for those codes exist (ICD-9, ICD-10, CPT).

Flex Code Group

A flex code group is a grouping of a number of flex codes that belong to the same flex code definition. Flex code groups can be used in dynamic logic, thus reducing the required complexity for the groovy scripts. A flex code group consists of:

Field	Description
Code	The identifying code of flex code definition
Description	A description of this flex code definition
Flex Code Definition	The definition to which all flex codes in this group must belong.
List of codes	The flex codes that belong to this group

Consider scenario where a payer sets up a flex code definition for person’s occupations. This flex code definition lists over a hundred occupations, that is, flex codes. For benefit adjudication purposes, the payer wants to divide those occupations over several axis:

• Indoor versus outdoor

• Office hours versus irregular hours.

• Hazardous versus low health risk.

The payer creates six flex code groups: INDOOR, OUTDOOR, OFFICEHOURS, IRREGHOURS, HAZARD and LOWRISK. Each occupation flex code in the flex code definition is assigned to one of the groups on each axis.

As a result, whenever the payer sets up a benefit that applies only to persons with hazardous outdoor occupations, the dynamic logic condition that checks this would contain the simple logic: "Is the person’s occupation in both the OUTDOOR and HAZARD flex code group?", rather than listing each occupation flex code that qualifies inside the groovy script.

Procedure codes, diagnosis codes and provider codes formats are also specified by flex code definitions. However there are several important notes on definitions that are used for this purpose:

• These flex code definitions only specify two fields: a key field and a descriptor field. Any other flex code field usages that are specified under the flex code definition are ignored.

• The key field is up to max 30 characters long and the descriptor field is up to max 99 characters long. If a greater length is specified in the definition, then this is ignored.

• The link between the procedure/diagnosis/provider table and the flex code sets that define their respective codes is OHI Claims implementation setup and is not configurable via a dynamic field usage.

• The flex code sets that define procedure/diagnosis/provider code may be extended by new flex code definitions at any time.

• Flex code groups are not used to group procedures, diagnoses or provide. Other entities exist for this purpose, i.e., provider groups, procedure groups and diagnosis groups.

Scenarios

Scenario: extending a person with an occupation field

A payer wants to extend the relation table with a dynamic field that contains a person’s occupation. The payer wants to bound the possible values to a domain, so this dynamic field references a flex code system containing the allowable occupations. Each occupation consists of three parts: a code, a description and a risk level. Each person can have an occupation. Organizations cannot have occupations.

Creating a dynamic flex field is set up in four steps:

1. Create flex fields

2. Create the flex code definition & flex code field usages.

3. Create the flex codes that represent that allowed occupations.

4. Create the dynamic field usage that extends the relation table

A dynamic field of the 'flex code' sub type is bound by a predefined domain of values. Step one & two describe exactly what is required to set up such a domain. In step three the actual domain of allowed values is defined. Step four how to extend a table with a field that holds an occupation.

A flex code should be regarded as a record rather than a single value. A flex code definition and pertaining flex code field usages specifiy the record properties such as the number of columns are included in the record and the column names, data types etc.. To specify this layout, the flex code field usages makes use of flex fields.

The payer creates three new flex fields

• Code 'C4', Description 'Generic text 4 chars', Length 4, Type 'Value', Data type 'Char'

• Code 'C60', Description 'Generic text 60 chars', Length 60 Type 'Value', Data type 'Char'

• Code 'C1, Description 'Generic text 1 char', Length 1, Type 'Value', Data type 'Char'

None of the value fields have a dynamic logic validation. None of the fields have a number of decimals.

Once the Fields have been set up, the next step is to specify how those fields are ordered to compose an 'occupation' flex code. The payer creates a flex code definition and a number of pertaining flex code field usages:

• Code - This is the 'name' of the the Flex Code Definition. This code is used to reference this definition in other pages.

• Description - A descriptive text to clarify the content of this definition.

A Flex Code Definition must have one or more flex code field usages. Each represents a column in the record that makes up the Flex Code. A Flex Code Field Usage has the following properties:

• Field - This is the Field that specifies this 'column' of the Flex Code Definition.

• Code - This is the name of the Flex Code Field Usage.

• Display name - This is the column header in the Flex Code entry page.

• Display sequence - The sequence of the column in the Flex Code entry page.

• Key? - Indicates whether this Field is the key Field.

• Descriptor? - Indicates whether this Field is the descriptor Field.

• Mandatory? - Indicates whether this Field is a mandatory Field.

• Allowable Values - Domain of possible values for this field.

Exactly one of the usages must represent the 'key' Field. The key field contains the unique identifier of a Flex Code, that is, unique within the context of the Flex Code Definition. One of the usages may represent the 'descriptor' Field. The descriptor and key fields are displayed in user interface look-up tables.

The payer starts by creating a new flex code definition. The payer specifies the code as 'OCCUPATIONS' and the description as 'Person occupations'.

An occupation flex code consist of three fields (code, description & risk), so the payer creates three new flex code field usages:

• Field 'C4', code 'CODE', display name 'Code'. Key field. Because key is checked this field defaults to mandatory and the display sequence defaults to 0.

• Field 'C60', code 'DESC', display name 'Description'. Descriptor field. The display sequence is set to 1.

• Field 'C1', code 'RISK', display name 'Health risk' & we specify this field as optional. We set the display sequence to 2. The allowable values attribute refers to another flex code definition that only allows the values H (high) and L (low).

The result of our setup is that we have created a virtual table within OHI Claims that has three columns. The next step is to populate that table.

Once the definition and field usages have been set up, the definition can be populated by Flex Codes. The properties of a flex code are exactly those fields that are defined in the pertaining flex code definition, plus a start and end date. So the properties of a flex code belonging to the OCCUPATION definition would have the following properties:

• Occupation code - The identifying code by which this occupation is known. This code is used to reference this field in other pages.

• Occupation description - A descriptive text of the occupation.

• Occupation health risk - An indicator for the health risk involved for this occupation.

• Start Date - The start date when this is a valid occupation

• End Date - The last date on which this occupation is valid.

The payer enters the following flex codes for the OCCUPATION definition:

Code	Description	Health risk	Start date	End date
FIRE	Firefighter	H	2009-01-01	n/a
SURG	Surgeon	L	2009-01-01	n/a
PARA	Paramedic		2009-01-01	n/a

Note that the payer may leave the 'Health risk' field empty because that field is specified to be optional.

Once the flex code definition and the flex codes have been defined, the payer has the equivalent of a new populatedAs covered by the Extending Tables chapter on dynamic fields, this is accomplished by creating a new dynamic field usage:

The payer sets uo a new dynamic field usage for the relation table. The name of this field is ''primaryOccupation' and the display name is 'Occupation'. The payer sets the type to 'Flex Code' and the flex code system to 'OCCUPATION'.

Because it is possible (and even likely) that a person changes his occupation over time, the payer chooses to make the occupation field time valid, by checking the time valid indicator. The value of the occupation field is not unique, not multi value and not (conditionally) mandatory. The payer sets a condition that imposes that only a person can have an occupation (as opposed to an organization).

As a result, the relation user interface page now shows a new field, labeled 'Occupation' that displays the key & descriptor field, start & end date of an occupation. It is possible for a particular person to change an existing occupation by making use of a look-up table (LOV), or end an existing occupation and choose a new one with a later start date. The occupation field also becomes available as an attribute of a relation in the object layer, that is, in groovy dynamic logic scripts.

Note that the setup of this dynamic flex field includes three different time periods, all of which have a different meaning:

• Time validity of a flex code value - This time period reflects when the occupation was a valid occupation in general. For example, the occupation 'surgeon' was time valid from 2000-01-01 until 2008-12-31. After that the payer decides that a more granular setup is needed for that occupation and adds new flex codes for 'heart surgeon', 'neurosurgeon' & 'other surgeon', all of which start on 2009-01-01.

• Time validity of a dynamic field value in context of the entity - This time period reflects when a particular person actually was a surgeon. For example, Mr. Jones is a surgeon from 2003-01-01 until 2006-07-23 and a firefighter from 2006-07-24 to the present day. This type of time validity is optional and depends on the setup of the pertaining Dynamic Field Usage. This type of time validity is important for dynamic fields that can possibly affect claims processing: suppose that a person’s occupation affects the way a claim is processed. That means that when processing a claim with a service date in the past, OHI Claims Adjudication and Pricing would need to know what a person’s occupation was at that time, regardless of the current occupation of that person.

• Time validity of a dynamic field usage - This time period determines when the OHI Claims Adjudication and Pricing user is actually allowed to add an occupation to a relation. This is further explained in the Extending Tables on dynamic field usages.

Scenario: specifying a code definition for Procedures

A flex code definition has one of two purposes: either it is set up to be used as a value domain for a dynamic field usage, or it is set up to serve a definition for diagnosis, procedure or provider codes.

The previous scenario covered the setup for a flex code definition used for a dynamic field usage. A flex code definition for a procedures, diagnoses or provider code system are essentially no different, with the exception that they validate procedure, diagnose or provider codes, instead of flex codes. This scenario covers only procedure codes, but the same holds true for diagnosis and provider codes.

Why does OHI Claims use a flex code definition to specify procedure codes?

• One payer may have to deal with multiple procedure code definitions. For example, the United States have different code definitions for the ICD-9, ICD-10, CPT and NDC procedures. It is quite possible that different procedure code definitions have overlapping codes, so it is imperative that each procedure code keeps track of the definition to which it belongs. For example, code 1234 may be a valid code in both the ICD-9 and ICD-10 procedure definition, but have a different meaning in either definition.

• Using a flex code definition allows a user to extend a table with a dynamic field that holds a reference to an actual procedure, diagnosis or provider, rather than simply a code. For example, a payer can extend the claim line table with an 'admitting diagnosis' dynamic field. The set of allowable values for this field would then be derived from the diagnoses present in OHI Claims Adjudication and Pricing.

• Validating a procedure code by a through a flex code definition allows a payer to define a specific code format per definition. For example, it can be enforced that an ICD-9 code always consists of between 2 and 4 digits and that the second and third digit are always separated by a decimal point.

There are two peculiarities with regard to flex code definitions that specify a procedure code:

• The definition only holds two fields: a key field for the code, and a descriptor field for the procedure description. Any additional flex code field usages are ignored by the system.

• The Flex Code Definition is not linked to the Procedure through a Dynamic Field Usage. Instead, that Flex Code Definition is added to a dedicated Flex Code Set. Once a definition is added to this dedicated set it can automatically be used to define procedures. This dedicated Flex Code Set is specified during an OHI Claims Adjudication and Pricing implementation.

The payer wants to set up a new flex code definition for the National Drug Code system (NDC). These NDC codes have a specific format. The code is composed of three sections. The first section specifies the product labeler, the second the product segment and the third the package segment.

Even though NDC codes are composed, the payer decides to use a flex code definition. The reason is that the meaning of the second and third code segments depend entirely on the first part of the code. Therefore, even though an NDC code is segmented, the parts cannot be used separately nor independently.

The payer creates two flex fields:

• Code 'NDC', Description 'National Drug Code', Length 12, Data type 'Char', Validation 'NDCVAL'

• Code 'C60', Description 'Generic text 60 chars', Length 60, Data type 'Char'

The dynamic logic validation 'NDCVAL' holds a regular expression that ensures that NDC codes exist in one of the following groupings of digits into segments: 4-4-2, 5-3-2, or 5-4-1.

The flex code definition must consist of two fields (code and description), so the payer creates two new flex code field usages:

• Field 'NDC', code 'CODE', display name 'Code' . Key field. Because key is checked this field defaults to mandatory and the display sequence defaults to 0.

• Field 'C60', code 'DESC', display name 'Description'. Descriptor field. The display sequence is set to 1.

The result is a flex code definition that consists of two fields. In order to make this definition available for procedures, the payer is required to add the definition to the flex code set that designated as the flex code set for procedure codes. This set is marked by a technical flag that is not configurable through the OHI Claims Adjudication and Pricing user interface pages. The 'procedure' flex code set is set up and marked as part of the implementation of OHI Claims Adjudication and Pricing.

The payer adds the NDC flex code definition to the flex code set named PROCEDURES. By doing so, the NDC definition becomes one of the available definitions for a procedure code.

The image shows the result of the setup described in this scenario. Each procedure record keeps track of the flex code definition by which it is defined, therefore imposing any validations associated with that definition on the procedure code. A procedure may belong to any one definition that is part of the 'procedure' flex code set.