NIH | National Cancer Institute | NCI Wiki  

Error rendering macro 'rw-search'

null

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Contents of this Page

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

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:
image of 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

Field Name

Value

codingSchemeGuid

<generated value>

codingSchemeName

ICD-10-TO-9-DIAG-GEM

codingSchemeUri

urn:oid:11.11.0.71

representsVersion

<provided by user>

formalName

ICD-10-TO-9-DIAG-GEM

defaultLanguage

ENG

approxNumConcepts

Null

description

ICD-10 CM to ICD-Volume 1 and 2 CM Volume 1 and 2 General Equivalence Mapping

copyRight

Centers for Medicare & Medicaid Services (CMS)

isActive

Null

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

releaseGuid

Null

codingSchemeSource

U.S. Department of Health and Human Services, Centers for Medicare & Medicaid Services

entryStateGuid

Null

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

Table: supportedAttrib, tag: CodingScheme

Field Name

Value

csSuppAttribGuid

<generated>

codingSchemeGuid

<from codingScheme table>

supportedAttributeTag

CodingScheme

id

ICD-10-TO-9-DIAG-GEM

uri

urn:oid:11.11.0.71

idValue

<blank>

associationNames

Null

rootCode

Null

isForwardNavigable

Null

isImported

1

equivalentCodingScheme

Null

assemblyRule

Null

assnCodingScheme

Null

assnNamespace

Null

assnEntityCode

Null

propertyType

Null

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

Field Name

Value

supportedAttributeTag

property

id

definition

idValue

definition

propertyType

PRESENTATION

Table: supportedAttrib (abbreviated), tag: EntityType

Field Name

Value

supportedAttributeTag

EntityType

id

ASSOCIATION

idValue

ASSOCIATION

Table: supportedAttrib (abbreviated), tag: EntityType

Field Name

Value

supportedAttributeTag

EntityType

id

CONCEPT

idValue

CONCEPT

Table: supportedAttrib (abbreviated), tag: Association

Field Name

Value

supportedAttributeTag

Association

id

hasSubType

idValue

hasSubType

Table: supportedAttrib (abbreviated), tag: Association

Field Name

Value

supportedAttributeTag

Association

id

isA

idValue

isA

Table: supportedAttrib (abbreviated), tag: Association

Field Name

Value

supportedAttributeTag

Association

id

mapsTo

idValue

mapsTo

Table: supportedAttrib (abbreviated), tag: Association

Field Name

Value

supportedAttributeTag

Association

id

contains

idValue

contains

Table: supportedAttrib (abbreviated), tag: Association

Field Name

Value

supportedAttributeTag

Association

id

ENG

idValue

CONCEPT

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

Field Name

Value

entityGuid

<generated >

codingSchemeGuid

< from codingScheme table>

entityCode

combination2

entityCodeNamespace

urn:oid:11.11.0.71

isDefined

Null

isAnonymous

Null

description

020.1 AND 020.3

isActive

1

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

< generated - used with revisions >

forwardName

Null

reverseName

Null

isNavigable

Null

isTransitive

Null

Table: entityType

Field Name

Value

entityGuid

< from entity table>

codingSchemeGuid

CONCEPT

Table: property

Field Name

Value

propertyGuid

<generated >

referenceGuid

< guid from entity table>

referenceType

entity

propertyId

definition

propertyType

presentation

propertyName

definition

language

ENG

format

Null

isPreferred

1

matchIfNoContext

0

degreeOfFidelity

<blank>

representationalForm

Null

propertyValue

020.1 AND 020.3

isActive

Null

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

< generated> used if revisions

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

Field Name

Value

relationGuid

<generated >

codingSchemeGuid

<from codingSchme table>

containerName

icd10to9DiagnosisCmsRelations

isMapping

1

representsVersion

Null

sourceCodingScheme

Null

sourceCodingSchemeVersion

Null

targetCodingScheme

urn:oid:11.11.0.71

targetCodingSchemeVersion

< provided by user >

description

ICD-10 CM to ICD-9 diagnosis CMS relations container

isActive

Null

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

< generated>

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

Field Name

Value

associationPredicateGuid

<generated >

associationPredicateGuid

<from relation table>

associationName

mapsTo

Table: entity

Field Name

Value

entityGuid

<generated >

codingSchemeGuid

<from codingScheme table>

entityCode

mapsTo

entityCodeNamespace

urn:oid:11.11.0.71

isDefined

Null

isAnonymous

Null

description

the source object can be mapped to the target object

isActive

1

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

<generated >

forwardName

mapsTo

reverseName

<blank>

isNavigable

1

isTransitive

1

Table: entityType

Field Name

Value

entityGuid

<from entity table>

entityType

ASSOCIATION

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

Field Name

Value

entityAssnsGuid

<generated >

associationPredicateGuid

<mapsTo GUID from associationPredicate table >

sourceEntityCode

C01.00

sourceEntityCodeNamespace

urn:oid:2.16.840.1.113883.6.3

targetEntityCode

002.0

targetEntityCodeNamespace

urn:oid:2.16.840.1.113883.6.2

associationInstanceId

< generated >

isDefining

1

isInferred

Null

isActive

1

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

<generated - used with revisions>

Table: entityAssnsQuals

Field Name

Value

entityAssnsGuid

<generated >

referenceGuid

<from entityAssnsToEntity table>

qualifierName

approximate

qualifierValue

true

entryStateGuid

<generated - used with revisions>

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

Field Name

Value

entityAssnsGuid

<generated >

associationPredicateGuid

<mapsTo GUID from associationPredicate table >

sourceEntityCode

G12.3x1A

sourceEntityCodeNamespace

urn:oid:2.16.840.1.113883.6.3

targetEntityCode

combination2

targetEntityCodeNamespace

urn:oid:11.11.0.71

associationInstanceId

<generated >

isDefining

1

isInferred

Null

isActive

1

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

< generated - used with revisions >

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

Field Name

Value

entityAssnsGuid

<generated >

associationPredicateGuid

<contains GUID from associationPredicate table >

sourceEntityCode

combination2

sourceEntityCodeNamespace

urn:oid:11.11.0.71

targetEntityCode

020.3

targetEntityCodeNamespace

urn:oid:2.16.840.1.113883.6.2

associationInstanceId

<generated >

isDefining

1

isInferred

Null

isActive

1

owner

Null

status

Null

effectiveDate

Null

expirationDate

Null

entryStateGuid

< generated - used with revisions >

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)

Field Name

Value

codingSchemeName

ICD-9-TO-10-DIAG-GEM

codingSchemeUri

urn:oid:11.11.0.70

representsVersion

<provided by user>

formalName

ICD-9-TO-10-DIAG-GEM

defaultLanguage

ENG

description

ICD-9 CM Volume 1 and 2 to ICD-10 CM General Equivalence Mapping

copyRight

Centers for Medicare & Medicaid Services (CMS)

codingSchemeSource

http://www.cms.hhs.gov

Table: relation (abbreviated)

Field Name

Value

containerName

icd9to10DiagnosisCmsRelations

isMapping

1

sourceCodingScheme

Null

sourceCodingSchemeVersion

Null

targetCodingScheme

urn:oid:11.11.0.70

targetCodingSchemeVersion

<provided by user>

description

ICD-9 CM to ICD-10 diagnosis CMS relations container.

ICD9 to ICD10 procedure codes

Table: codingScheme (abbreviated)

Field Name

Value

codingSchemeName

ICD-9-TO-10-PROC-GEM

codingSchemeUri

urn:oid:11.11.0.72

representsVersion

<provided by user>

formalName

ICD-9-TO-10-PROC-GEM

defaultLanguage

ENG

description

ICD-9 CM Volume 3 to ICD-10 PCS General Equivalence Mapping

copyRight

Centers for Medicare & Medicaid Services (CMS)

codingSchemeSource

http://www.cms.hhs.gov

Table: relation (abbreviated)

Field Name

Value

containerName

icd9to10ProcedureCmsRelations

isMapping

1

sourceCodingScheme

Null

sourceCodingSchemeVersion

Null

targetCodingScheme

urn:oid:11.11.0.72

targetCodingSchemeVersion

<provided by user>

description

ICD-9 CM to ICD-10 procedure CMS relations container.

ICD10 to ICD9 procedure codes

Table: codingScheme (abbreviated)

Field Name

Value

codingSchemeName

ICD-10-TO-9-PROC-GEM

codingSchemeUri

urn:oid:11.11.0.73

representsVersion

<provided by user>

formalName

ICD-10-TO-9-PROC-GEM

defaultLanguage

ENG

description

ICD-10 PCS to ICD-9 CM Volume 3 General Equivalence Mapping

copyRight

Centers for Medicare & Medicaid Services (CMS)

codingSchemeSource

http://www.cms.hhs.gov

Table: relation (abbreviated)

Field Name

Value

containerName

Icd10to9ProcedureCmsRelations

isMapping

1

sourceCodingScheme

Null

sourceCodingSchemeVersion

Null

targetCodingScheme

urn:oid:11.11.0.72

targetCodingSchemeVersion

<provided by user>

description

ICD-10 CM to ICD-9 procedure CMS relations container.

  • No labels