Health Information Exchange

  • Reduce medication and lab errors
  • Reduce duplication, inefficiencies, save money
  • Support patient’s involvement in their own care
  • Reduce unnessary paperwork
  • Shared clincal support tools
  • Improves public health reporting and monitoring
  • Support for the patient across transitions of care
  • Perform longitudinal analyses of care

Levels of Interoperability

  • Level 1 – no interoperability
    • mail, fax, phone, etc.
  • Level 2 – machine-transportable (structural)
    • Information cannot be manipulated
    • scanned document, image, PDF
  • Level 3 – machine-organizable (syntactic)
    • Sender and receiver must understand same vocabulary
    • email, files in proprietary format
  • Level 4 – machine-interpretable (semantic)
    • Structured messages with standardized and coded data
    • coded results from structured notes, lab, problem list, etc.

Definitions

  • Terminology: “terms”
  • Concept: thing or idea, expressed in terms
  • Dictionary: concepts with their meaning
  • Thesaurus: terms and synonyms grouped by concept
  • Vocabulary: concepts and terms in a domain
  • Ontology: structured concepts and the relationships between them

Synonyms

When the various terms describe the same concept or condition. Lets take a look at the example of Prostate Cancer, identified by ICD-10 Code C61

SELECT DiagnosisName,
        Type, 
        Value
FROM deid_uf.diagnosisterminologydim
WHERE Type = 'ICD-10-CM'
  AND Value = 'C61'

Synonym Example

Polysems

When the same word has various different meanings, leading to lack of specificity. Lets look at the ICD-10 codes for “Depression” as an example.

SELECT DiagnosisName,
        Type, 
        Value
FROM deid_uf.diagnosisterminologydim
WHERE Type = 'ICD-10-CM'
AND 
DiagnosisName LIKE '%depression%'

Polysem Example

Diagnosis Code Terminologies

  • ICD9/10
  • SNOMED-CT
  • DRG

ICD

  • Initially developed in 1893 as International Causes of Death
  • Maintained and published by the WHO
  • Broadened to International Classification of Disease
  • ICD-9: released in 1975
  • ICD-9-CM: US Variation with an additional digit for specificit
  • ICD-10-CM: US transitioned in 2015

ICD

Limitations of ICD-9

  • ~13,000 codes
  • outdated: new diseases, new nomenclature
  • used digits instead of locations, so what happens when you have more than 10 options?
    • .1 means first type, .12 means the 12th type
  • limited granularity and specificity
  • cannot add modifiers for location, laterality, severity

ICD-10

  • 65,000+ codes
  • 3-7 characters
  • Characters 1-3: Category
    • Character 1 always alphabetic
    • Characters 2-3 always numeric
  • Characters 4-6: etiology, anatomic site, or other clinical detail
  • Character 7: extension

ICD-10

  • S: Injury
  • 52: Dislocation and sprain of joints and ligaments of elbow
  • .5: Fracture of lower end of radius
  • .52: Torus fracture of lower end of radius
  • .521: Torus fracture of lower end of RIGHT radius
  • .521A: Initial Encounter

ICD-10

ICD-10

ICD-10

ICD-10

Granularity can lead to absurdity

  • W55.29XA: Other contact with cow, subsequent encounter.
  • W220.2XD: Walked into lamppost, subsequent encounter.
  • W61.62XD: Struck by duck, subsequent encounter.
  • Y92.146: Swimming-pool of prison as the place of occurrence of the external cause
  • Y65.8: Other specified misadventures during surgical and medical care
SELECT YEAR(encounterfact.DateKeyValue),
       COUNT(*)
FROM deid_uf.EncounterFact
    LEFT JOIN DiagnosisTerminologyDim 
      ON DiagnosisTerminologyDim.DiagnosisKey = EncounterFact.PrimaryDiagnosisKey
WHERE
  DiagnosisTerminologyDim.Type = 'ICD-10-CM'
  AND 
  DiagnosisTerminologyDim.Value LIKE '%W61.62%'
GROUP BY YEAR(encounterfact.DateKeyValue)
ORDER BY YEAR(encounterfact.DateKeyValue)

Struck by a Duck

Encounters for patient Struck by a Duck(W61.62) at UCSF, by year
2014 1
2015 6
2016 16
2017 8
2018 3

SNOMED-CT

  • Systematized Nomenclature of Medicine
  • US English, UK English, Spanish, Danish and Swedish; being translated to others
  • 300,000 concepts – > 1M “descriptions” (terms) expressing concepts – > 1M relationships between concepts

  • SNOMED Browser: https://browser.ihtsdotools.org/

SNOMED-CT: Prostate Cancer

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

SNOMED-CT: COVID

Groupers

  • categories of codes to represent a clinical coherent event
  • MS-DRG
  • Internal EPIC and UCSF Groupers
  • your own custom groupers?

MS-DRG

  • Medicare Severity Diagnosis Related Groupers
  • 25 Major Diagnostic Categories created
  • within those, 761 total DRGs created
  • Each DRG A collection of diagnosis codes that can approximate patient complexity, for case-mix adjustment in Medicare bundled payment models
  • Each DRG should contain patients with similar levels of resource use intensity
  • Each DRG should contain patients who are similar from a clinical perspective (i.e., each class should be clinically coherent)
  • Recommendation: Only use this grouper if your project is replicating CMS models (case-mix adjustment for bundled payments)
  • DrgDim table

Internal Groupers

  • in Epic they are called Groupers. They exist for disease, medications, procedures, etc.
  • Diagnosis groupers are stored in the DiagnosisSetDim table, with the column DiagnosisName showing the text of each individual diagnosis and the column Name showing the name of the grouper.
SELECT DiagnosisName, ValueSetEpicId, Name
FROM deid_uf.DiagnosisSetDim
WHERE Name LIKE '%prostate cancer%'

Internal Groupers - Prostate Cancer

Internal Groupers - Prostate Cancer

SELECT 
DISTINCT ValueSetEpicId,Name
FROM deid_uf.DiagnosisSetDim
WHERE Name LIKE '%prostate cancer%'

Internal Groupers - Prostate Cancer

Internal Groupers

  • Grouper for metastatic prostate cancer is called UCSF EDG CONCEPT METASTATIC PROSTATE CANCER, with an ValueSetEpicId of 108748
  • I can link their DiagnosisKey in any table to the set of DiagnosisKeys in DiagnosisSetDim after I’ve limited my query to ValueSetEpicId = '108748'

Unified Medical Language System (UMLS)

  • compendium of existing vocabularies maintained by NLM
  • think of it as a big directory
  • organized by concept, each with specific attributes and linked to the corresponding concept names in the various source vocabularies
  • free to access
  • Full listof vocabularies: https://www.nlm.nih.gov/research/umls/sourcereleasedocs/index.html
  • Limitations
    • maps 1:1 relationships
    • lacks unifying hierarchy (partial)
    • not and ontology: minimal relationships or context

Procedure Codes

  • Healthcare Common Procedural Coding System (HCPCS)
  • HCPCS Level 1: CPT-4 (Common Procedure Terminology)
  • HCPCS Level 2: Items and Supplies and non-physician services not in Level 1
  • ICD-9-CM
  • ICD-10-PCS (Procedure Coding System): Used for inpatient settings only

DeID CDW Procedure Tables

  • ProcedureDim
  • ProcedureOrderFact
  • ProcedureSetDim
  • ProcedureTerminologyDim
  • ProcedureTerminologySetDim

ProcedureDim

SELECT TOP 10 *
FROM deid_uf.ProcedureDim
##  [1] "DeidLds"             "ProcedureKey"        "DurableKey"         
##  [4] "ProcedureEpicId"     "Name"                "ShortName"          
##  [7] "PatientFriendlyName" "Category"            "Code"               
## [10] "RevenueCode"         "CptCode"             "HcpcsCode"          
## [13] "AdaCode"             "AsaCode"             "OtherCodeType"      
## [16] "OtherCode"           "Level"               "StartDate"          
## [19] "EndDate"             "IsCurrent"           "CodeSet"            
## [22] "IdType"              "Id"

ProcedureDim

SELECT CodeSet,
       count(*)
FROM deid_uf.ProcedureDim
GROUP BY CodeSet

ProcedureDim

SELECT TOP 100 *
FROM ProcedureDim
WHERE CodeSet = 'Custom'

ProcedureDim

ProcedureDim

SELECT Category,
       count(*) AS n
FROM ProcedureDim
WHERE CodeSet = 'Custom'
GROUP BY Category
ORDER BY n DESC

ProcedureDim

Conclusion

  • Various diagnosis and procedure coding systems exist, each with advantages and disadvantages
  • When using a system, consider its intended purpose and actual use
  • Start broadly and narrow to the codes that are most relevant/used in your dataset (constantly balancing sensitivity and specificity of your query)
  • Do no assume codes are used as intended (false granularity, lazy data entry)