Page History
Scrollbar | ||
---|---|---|
|
...
Page info | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
Panel | ||||
---|---|---|---|---|
| ||||
|
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:
...
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 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.
...
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.
...
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.
...
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.
...
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.
...
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 |
---|---|
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 |
---|---|
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 |
---|---|
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. |
...
Scrollbar | ||
---|---|---|
|