Data Model of Modifiers in i2b2 

Introduced in Core i2b2 Version 1.6

In Version 1.6 of i2b2 we begin to use the modifier_cd column in the observation_fact table.

The use of this column allows a single fact to be modified with an unlimited number of codes, for example:

A drug can be modified with dose, route, and frequency.

A CPT procedure can be modified with standard CPT modifier codes such as 62 (two surgeons) and AA (anesthesia performed personally by anesthesiologist.) 

Essentially, the modifier is a way to extend the concept code. Much of what is expressed as a modifier could be expressed by making multiple concept-modifier combinations in the concept dimension, a simple and effective approach in many cases.  However, when modifiers are associated with values (such as with dose), or can occur in many combinations (as in CPT or SNOMED modifiers,) it becomes simpler to use the modifier_cd column.

In the fact table, the modifier is represented by the modifier_cd column, which is now part of the primary key on the fact table. This column is a varchar(50) and its codes are generally 1-30 characters with a 3-19 character prefix that represents the concept type and a variable-length suffix that describes the modifier, often with a colon separating the prefix from the suffix, for example MED:DOSE. However, the only true constraint is that the code is 50 characters or less. Just as concepts may have values associated with them (as with lab tests), or not; a modifier may have a value associated with it, as in the case of a medication dose, which has a numeric value representing the dosage amount; or it may be stand-alone, that is, it does not have an associated value, as occurs with CPT modifiers. In cases where there is a value associated with the modifier, the value is expressed in the columns of the fact table in the same way as values associated with other concept/value pairs, such as lab tests.

When modifiers are associated with an observation, there are at least two, and often multiple, rows for that observation in the observation_fact table. In the simplest form, there is a 'base' row representing the concept and one additional row per modifier. Sometimes a concept may be repeated more than once in a given encounter or visit, or one concept may be associated with more than one modifier of the same type, for example, when a medication is given with two different does. To handle this situation, the field instance_num is used, which groups facts into clusters and allows serveral of the same type of modifier to be attached to one fact. There are several options for use of the instance_num column, but in the simplest case it is an integer that ties together several rows representing the same observation.

Below is an example where there are no values associated with the modifier. This example is a CPT code for a Caesarian surgery performed on patient #123 at visit #107 on 3/4/2006. A CPT modifier is a two digit alpha or numeric code that indicates a procedure or service was altered in some way from the stated code descriptor without changing the definition. In this case the CPT modifiers are 62 = "two surgeons", AA = "anesthesia services performed personally by anesthesiologist", and TH = "Obstetrical treatment/services, prenatal or postpartum."

Example 1, CPT for Caesarian surgery with three modifiers for patient # 123 at visit #107 on 3/4/2010.

In example 2, a prescription is written for patient #123 at visit #567 for Aspirin 325 mg QD PO on 4/4/2010

If the patient was written for another baby (83 mg) Aspirin BID PO on the same day, it would be represented as:

Combining the results of examples 1 and 2 in the observation_fact table produces the following set of rows:

Looking at the medications in the example above, there are two entries for the concept med:aspirin. The only way to distinguish whether the 325 mg dose is QD or BID is to look in the instance_num column. Since the 325 mg dose has instance_num = 1, it is associated with the frequency for instance_num = 1, which is QD.

By default, the value information and data in all the non-key columns will be assumed to pertain to the modified concept, so there should usually be included a row for the base concept with an "@" in the modifier column. This will allow value information to be applied to the base concept code. Note that the modifier code is also a way that value information could be attached to the provider code.
The only change to a standard i2b2 database to enable it to work with modifiers is to add an instance number to the instance_num column. Most databases will begin with only one row per observation, and in those cases all rows can be initialized with an instance_num of "1".

The Modifier_Dimension Table and Ontology Table

The modifier_cd is a data element that describes attributes of a fact and it is a dimension column in the fact table.   Information about the modifier is contained in a new dimension table in the i2b2 star schema, the modifier_dimension table.

MODIFIER_DIMENSION TABLE
Clustered primary key = modifier_path

A modifier may be associated with a group of concepts, such as dose with medications, but it is usually not universal, that is, a particular modifier would not be associated with all concepts. For example, a dose can only modify a medication, it can't modify a diagnosis or procedure.  For this reason, the model for representing modifiers includes a new field in the ontology table, called m_applied_path, that indicates to which paths in the ontology hierarchy the modifier refers.

ONTOLOGY TABLE
Primary key = c_fullname + c_name

To illustrate the way the dimension and metadata tables work for modifiers, take the example of a disease, such as asthma, that can occur with varying degrees fo severity: mild, moderate and severe. These are the modifers for the concept 'asthma'. 

Before adding m_applied_path,  the concept looked like this in the ontology table:

Now, to add the modifiers, mild, moderate and severe, we add the new column, m_applied_path to the ontology table, and three new rows, one for each modifier: 

The field m_applied_path indicates which paths the associated modifier refers to.  The '%' wild card is used to indicate that the modifier refers to all extensions to the path 'Diagnoses\Respiratory disorders\'

© Shawn Murphy 2011