Source Data, General Comments

General Equivalence Mappings, or GEM, is the mappings between ICD-9 and ICD-10 concept codes. There are four types of mappings:

• 9 to 10 diagnosis codes
• 9 to 10 procedure codes
• 10 to 9 diagnosis codes
• 10 to 9 procedure codes

Each mapping is one text file with three white space separated columns. Column one is the source concept code, column two is the target concept code and column three is a five digit numeric character field that describes the relationship between the source and target codes. For detailed information on how to interpret the relationship details the reader is referred to either one of the following documents below.

Mapping guide for PCS data

• go to: http://www.cms.gov/ICD10/13_2010_ICD10PCS.asp,
• click on: "2010 Mapping - "ICD-10-PCS to ICD-9-CM" and "ICD-9-CM to ICD-10-PCS"; and User Guide, Reimbursement Guide - Procedures (ZIP, 0.98MB) - Updated 3/12/10"
• documentation referred to for mapping is: pcs_gemguide_2010.pdf and is in the ZIP file.

Mapping guide CM data

• go to: http://www.cms.gov/ICD10/14_2009_ICD_10_CM.asp
• click on: 2009 Diagnosis Code Set General Equivalence Mappings (ZIP 1.1MB)
• documentation referred to for mapping is: Dxgem_guide_2009.pdf and is in the ZIP file.

Decimal Point

The ICD-9 diagnosis codes, ICD-9 procedure codes and ICD-10 diagnosis codes concept codes in the mapping files do not contain decimal points. The loader will format the values with decimal points as needed.

Mappings

General Comments

Terms

The term 'map' or 'mappings' gets overloaded a bit in this document. In one context it may refer to the GEM data, which is a map (one concept maps to another concept or set of concepts). While in another context how the GEM data gets converted into LexGrid objects is a map.

GEM to LexGrid Coding Scheme

For each GEM data set loaded, a LexGrid coding scheme will be created.

Overview

The GEM contains information that maps concepts to one another. This kind of data is represented in LexGrid as an association. So the coding scheme will consist of mostly associations. In some special cases, a concept will be created which will be detailed later in this document.

Consider the image below of a small set of GEM mapping data:

The loader creates a default root node @, and each unique occurrence of source concept code in the GEM file is associated with the root node via hasSubType association (A). The GEM data is mapped to instances of LexGrid associations that have a source concept code and target concept code. GEM can have a few types of situations the loader must handle. Case B, shows a single mapping. The type of association used is 'mapsTo'. For each mapsTo instance, a qualifier is set (approximate true or false) indicating if the two concepts are an exact mapping. In B's case it is set to false, meaning it is an exact map.

GEM data is not always a straight one-to-one mapping. Sometimes a combination of target concepts represent the desired map. Or there may also be a number of possible target maps. An example of this is shown in C. When a combination map is found in the data, the loader will create a 'concept' that represents combination map. Also, the individual concepts that make up the combination are recorded in LexGrid using another association type created by the loader named 'contains'. An instance of the contains association D, where the source is the combination concept and the targets are the individual concepts.

For details on how combination maps are derived please see the GEM guides referenced above in the Source Data, General Comments section.

GEM data may also contain occurrences of data where there is no map for a particular concept. This is show in E, F where the association type is mapsTo and the target value is NoDx.

GEM metadata to LexGrid

What is meant by GEM meta data is data that would describe the GEM data, such as version, name etc... This kind of data is
stored in LexGrid as coding scheme information and coding and supported attributes. However, none of this type of nformation is provided in the GEM data files. So the loader will populate this data with default values. When the loader is executed must be given a file location, version, and GEM type. The loader will fill in the default data based on the GEM type supplied to it.

Table: codingScheme

Also, the following attributes are supported by the coding scheme:

Table: supportedAttrib, tag: CodingScheme

In the tables that follow, all showing values from LexGrid table supportedAttrib (as above), only fields with non-null values and non-generated values will be displayed.

Table: supportedAttrib (abbreviated), tag: Property

Table: supportedAttrib (abbreviated), tag: EntityType

Table: supportedAttrib (abbreviated), tag: EntityType

Table: supportedAttrib (abbreviated), tag: Association

Table: supportedAttrib (abbreviated), tag: Association

Table: supportedAttrib (abbreviated), tag: Association

Table: supportedAttrib (abbreviated), tag: Association

Table: supportedAttrib (abbreviated), tag: Association

Concepts

As mentioned in the Mappings: General Comments section, GEM mapping data, much of it anyway, is represented in LexGrid as associations. However some concepts are created by the loader in cases where GEM target data is a combination of concept codes.

When an concept is created the LexGrid tables entity, entityType and property are updated.

Table: entity

Table: entityType

Table: property

Relations

A LexGrid relation container is defined to hold LexGrid association definitions (mapsTo, contains, etc). Instances of the defined associations are created to represent the GEM data. Note the isMapping flag is on to indicate the associations are mappings.

Table: relation

Associations

LexGrid uses associations to represent GEM data. The loader creates a root concept, @, that is the root of the hierarchy. Source concept codes in the GEM are associated with @ via the hasSubType association. GEM source and target code relationships are represented by the association mapsTo. If there is a combination of concept codes that represent the target in a mapping, the combination concept is associated with the individual concept codes with a contains association.

For each association an entry will be made in the following tables: associationPredicate, entity, entityType. Only mapsTo is shown in the examples below.

Table: associationPredicate

Table: entity

Table: entityType

OIDs

A note about the above entityCodeNamespace value. While official vocabularies and terminologies like ICD-9 and ICD-10-CM have registered unique Object IDentifiers (OIDs) mappings don't seem to. So for the GEM mappings arbitrary values were chosen and used as default values in the GEM loader. For more information on OIDs: http://www.oid-info.com/

GEM data and LexGrid associations

In a general sense the GEM data consists of a source concept code and a target concept code and information describing the relationship. These relationships are described in LexGrid as an instance of a particular kind of association with source and target information. The key pieces of LexGrid data are the sourceEntityCode (from the first column of GEM data) , targetEntityCode (second column of GEM data) sourceEntityCodeNamespace (information that indicates the terminology the source code came from- usually a URI or URN value) and targetEntityCodeNamespace and finally the reference back to what type of association this is (mapsTo, hasSubType etc) via the associationPredicateGuid.

A couple examples may help. If we use the mapping illustrated in figure 1 above, an ICD-10-CM to ICD-9 diagnosis codes) we can see C01.00 maps to 002.0. And the mapsTo association has a qualifier that says this is an approximate is true. For this example we will only examine the mapsTo association. Note however the loader also creates a @ hasSubType C01.00 association.

Table: entityAssnsToEntity

Table: entityAssnsQuals

The loader knows this is a GEM mapping of ICD-10 to ICD-9 diagnosis codes. The loader will only know this from the mapping-type parameter passed to it when it is executed. So sourceEntityCode is formatted with a decimal and the sourceEntityCodeNamespace is given the URN for ICD-10 CM. Likewise the targetEntityCode is formatted and the targetEntitycodeNamesapce is give the ICD-9 URN. The link back to the defining association (mapsTo) is provided with associationPredicateGuid. Also note, this association had a qualifier so the entityAssnQuals table was updated. The referenceGuid value is the link back to the association this qualifier belongs to.

Now for an example of a combination target code. Again, referring to figure 1 above, we can see the mapping:

G12.3x1A mapsTo combination2 and combination2 contains 020.1 and 020.3

In this example we will look at the mapsTo and contains associations. Reminder: the loader will also create a hasSubType association. The mapsTo association qualifier value is handled as described above.

Table: entityAssnsToEntity

In this case, the loader created a concept called combination2 to represent the combination of target codes that the source concpet code maps to. Note, this is a concept created local to this mapping coding scheme so sourceEntityCode combination2 has a sourceEntityCodeNamespace of urn:oid:11.11.0.71 which is the namespace of this LexGrid coding scheme. For a bit more detail on the GEM coding scheme namespaces see the OIDs section under the Association section above.

Table: entityAssnsToEntity

The associationPredicateGuid refers back to the contains association and the target information, code format and namespace value are set appropriately for the ICD-9 target vocabulary.

Default Data

The example above showed default data for a ICD-10-CM to ICD-9 diagnosis codes GEM. The default data used by the loader for the other GEM data sets is shown in this section.

ICD9 to ICD10 diagnosis codes

Table: codingScheme (abbreviated)

Table: relation (abbreviated)

ICD9 to ICD10 procedure codes

Table: codingScheme (abbreviated)

Table: relation (abbreviated)

ICD10 to ICD9 procedure codes

Table: codingScheme (abbreviated)

Table: relation (abbreviated)