ohdsi / oncologywg Goto Github PK

• Example 1: Name change examples stable identifier stays stable (ICD10CM).
  • Reason: Giving more explicit definition of a disorder. In this case we just keep the last version of the name.
  • Revise from: Panic disorder without agoraphobia
  • Revise to: Panic disorder [episodic paroxysmal anxiety]
  • Reason: Typo
  • Revise from: Trichiasis without entropian
  • Revise to: Trichiasis without entropion

Before:

After:

• Example 2: Concept deprecation (ICD10CM).
  • Reason: The concepts created by mistake. There're two phalangs only in thumb, so "proximal or distal interphalangeal joint" localization is applied to other fingers but not a thumb. In this case we put the date of concept withdrawal and mark invalid_reason as "D" (deprecated).
  • Deprecation: Subluxation and dislocation of proximal interphalangeal joint of thumb
  • Deprecation: Subluxation and dislocation of distal interphalangeal joint of thumb

Before:

After:

• Example 3: Relationship assertion between two concepts retired.
  • Reason: Better relationship found (it relates now "Laryngeal structure" and "Neoplasm of uncertain behavior" respectively). We put the date of relationship withdrawal and mark invalid_reason as "D" (deprecated)
  • Deprecation: 22274(Neoplasm of uncertain behavior of larynx) Has finding site 4240671 (Anatomical structure)

Before:

After:

We are planning on ingesting the Observational Research in Oncology Toolbox(OROT) into the OMOP vocabulary tables to provide a bridge between the low-level codes used in observational sources (EHRs/claims databases) to higher-level Procedure/Treatment concepts to be placed in the episode_object_concept_id column in the EPISODE table for 'Treatment Regimen '/'Treatment Cycle' episodes. See here: https://seer.cancer.gov/oncologytoolbox/

We are asking NCI/SEER to add some formal ontology properties to OROT to facilitate the ongoing ingestion of OROT into the OMOP tables.

Formal Ontology Properties

• Use RxNorm codes as an anchor code for each entry.
• Use a stable identifier for classification concepts ('SEER*Rx Category', 'Major Drug Class' and 'Minor Drug Class').
• Timestamp the retirement of classification concepts (valid_start_date, valid_end_date).
• Distribute the OROT classification concepts in a separate file from the classification assertions.
• Timestamp the retirement of classification assertions. For example, if a HCPCS/NDC/RxNorm code moves from 'Chemotherapy' to 'Immunotherapy' in the SEER*Rx Category, please update the valid_end_date for the existing classification assertion and add another row with the new classification assertion with a valid_start_date.

NAACCR Ingestion into OMOP Vocabulary - Diagnostic Modifiers.docx

This documentation will be the basis for a public facing website and content for tutorials.

• Describe overall description and mission of the project.
• Describe major entities and concepts.
• Instructions for implementing the oncology extension.
• Include use cases on public facing website.

At the CDM and Vocabulary Development Working Group meeting on 12/4/2018, the issue was raised whether the linkages between the EPISODE table and clinical event tables should be made at all levels of an episode hierarchy or only at the leaf. A convention should be decided upon and recommended in the EPISODE_EVENT table conventions documentation. Options:

1. Only link at the leaf level of an episode hierarchy.
   For example, if an episode hierarchy includes a 'Treatment Regimen' episode as the parent of one or more 'Treatment Cycle' episodes, only link clinical events via the EPISODE_EVENT table to the 'Treatment Cycle' episode.
2. Link all levels of an episode hierarchy.
   For example, if an episode hierarchy includes a 'Treatment Regimen' episode as the parent of one or more 'Treatment Cycle' episodes, link clinical events via the EPISODE_EVENT table to the both the ''Treatment Cycle' and 'Treatment Regimen' episode.

Dmytry's ingestion script needs to be frontloaded with a curated list of NAACCR items/NAACCR item codes. The curated list should be maintained in the OncologyWG repository. The curated NAACCR list should identify the following:

• NAACCR items/NAACCR item codes to be ingested.
• Numeic NAACCR items.
• Date NAACCR items .
• The OMOP vocabulary domain of each NAACCR item/NAACCR item code.

At the 4/16/2019 OHDSI Oncology Workgroup meeting we decided the following:

'Hemong.org' regimen concepts should be placed in the 'Drug' domain as standard concepts. 'Hemong.org' regimen category concepts should be placed in the 'Drug' domain as standard concepts.

Duplicates #22

We need to calculate the delta between different versions of NAACCR. The SEER API should be able to be used at least on the NAACCR item level and non-schema specific NAACCR item code level to give us the ability to compare different versions of NAACCR. If NAACCR item numbers and NAACCR item codes are stable over time then the representation of NAACCR version within OMOP will be unnecessary.

• If ingesting, they should be mapped to 0.
• If not ingesting, should we add them to the vocabulary so that they are recognized?

The idea is that in the end NAACCR will be a 'source' vocabulary and that Nebraska Lexicon will be the 'standard' vocabulary for condition/disease episodes. This will task will be a placeholder for mapping all anatomic sites in NAACCR to all anatomic sites in the Nebraska Lexicon. Each anatomic site or groups of anatomic sites will have separate tasks.

@dimshitc has already published the first version of the Hemonc.org regimen ontology within Athena. See here for an example Hemonc.org regimen:
http://athena.ohdsi.org/search-terms/terms?conceptClass=Regimen&vocabulary=HemOnc&page=1&pageSize=15&query=R-CHOP

So no need to review the staging area. We can review the real thing.

We need to update the
ETL Instructions for Mapping ICDO to SNOMED'
to include NAACCR as a source and target the Episode table.

A modified measurement table or a new modifier table or something else.

• MEASUREMENT with polymorphic key
  • Pros
    • Not a new redundant structure.
    • Some modifiers can be recorded independent of a diagnosis.
  • Cons
    • Nullable foreign key.
• MODIFIER table
  • Pros
    • Constrained by a domain to distinguish which measurements are modifiers.
    • No nullable foreign key.
  • Cons
    • Some modifiers can be recorded independent of a diagnosis.
    • Add new redundant structure.
• Other option?

Recommend creating a new 'Procedure/Treatment' domain. There exist currently concepts in the 'Procedure Domain' that are more akin to the concept of a Treatment than a Procedure. These concepts most properly belong to a Treatment domain but we don't want to force users to create Treatment Episodes that just want to stick with Procedures.

Ingest concepts into the 'Procedure/Treatment' domain based on NAACCR treatment variables. Reuse standardized SNOMED concepts when possible. Will require moving some concepts from the 'Procedure' domain to the new 'Procedure/Treatment' domain.

CONCEPT

For example NAACCR #752 'Tumor Size Clinical', has the following list of NAACCR item codes

  000 	  No mass/tumor found
  001 	  1 mm or described as less than 1 mm
  002-988 Exact size in millimeters (2 mm to 988 mm)
  989     989 millimeters or larger
  990     Microscopic focus or foci only and no size of focus is given
  999     Unknown
          Size not stated
          Not documented in patient record
          Size of tumor cannot be assessed
          Not applicable

Rimma's proposed solution: The NAACCR item should contain no list of possible values in the 'Meas Value' domain and should be recorded in Measurement.value_as_number as it appears in the source.

• CPT
• ICD10-PCS
• SNOMED

There are two types of provenance concepts: one describing diagnostic source (e.g. pathologist, clinician) and another describing record source (e.g. pathology report, EHR). Which one should we use? Or should we simply import these as separate Measurement entries?

This will be necessary for both the Nebraska Lexicon and NAACCR. ETL developers will need to know if I have a diagnosis/condition in anatomic site X, then give me the list of possible modifiers.
See #6 and #7.

See input

• Include a stable identifier/CUI for each concept (Class or Individual) in the ontology and timestamped begin/end dates for each concept and concept relationship (Property Assertion) in the ontology.

Now that Hemonc.org is in the OMOP vocabulary tables we can do this on our side.

In the most current version of the Oncology/Episode of Care Combined Proposal #23, the polymorphic pair of columns that allow the EPISODE_EVENT table to reference any clinical event table are named 'event_id' and 'event_table_concept_id'. This diverges from the current OMOP naming convention for polymorphic column pairs:

• NOTE.note_event_id, NOTE.note_event_field_concept_id
• COST.cost_event_id, COST.cost_event_field_concept_id

Options:

• EPISODE_EVENT.event_id, EPISODE_EVENT.event_table_concept_id
• EPISODE_EVENT.event_id, EPISODE_EVENT.episode_event_field_concept_id
• EPISODE_EVENT.episode_event_id, EPISODE_EVENT.episode_event_field_concept_id

DOMAIN

VOCABULARY

CONCEPT_CLASS

CONCEPT

• CPT
• ICD10-PCS
• SNOMED

See decision made in #20. The DDL SQL does not follow this decision. Needs to be fixed.

Options:

• FACT_RELATIONSHP as is today.
• EPISODE_EVENT with polymorphic foreign key
• EPISODE_EVENT with multiple foreign keys
• Multiple EPISDE_EVENT tables for each clinical event table.

Currently the SEER API only provides possible values for Union for International Cancer Control (UICC) TNM 7th edition classification? TNM categories, stage groups, and definitions are based on the Union for International Cancer Control (UICC) TNM 7th edition classification. UICC 7th edition and AJCC 7th edition TNM categories and stage groups are very similar; however, there are some differences.

Should we try to obtain possible values for other TNM versions? This would require that ETL writers would need to scope the look up of their staging variables with NAACCR item #1060 TNM Edition Number. See here:http://datadictionary.naaccr.org/default.aspx?c=10#1060

• Parse input. Create attribute-value relationship.
• Link to sites: breast, colon
• Replace LOINC attribute codes with SNOMED when available

VOCABULARY

CONCEPT_CLASS

CONCEPT

• Call the SEER API to ingest into the OHDSI vocabulary tables NAACCR data item/data item categorical values.
  • Get an account and API key from here: https://api.seer.cancer.gov/new_account
  • Return all NAACCR item numbers/item names for the latest NAACCR version from this REST resource: https://api.seer.cancer.gov/rest/naaccr/latest. This will return an array of hashes for reach NAACCR data item with the following JSON object structure: { "item": 10, "name": "Record Type" }
  • For each NAACCR data item, call the REST resource (replacing 10 with each NAACCR data item number): https://api.seer.cancer.gov/rest/naaccr/latest/item/10. This will return a hash with the following structure (the “documentation” key value can be seen in the separate file ‘documentation.html’): { "item": 1390, "name": "RX Summ--Chemo", "start_col": 2243, "end_col": 2244, "alignment": "RIGHT","padding_char": "0", "documentation": “documentation.html” }
    • Parse the HTML value in the “documentation’ key. Here are CSS selectors that will help you find the right content:
      • ‘div.content.chap10-para .code-row’ This will find each categorical value for the NACCAR data item.
      • ‘td.code-nbr’ to find the code value
      • ‘td.code-dsc’ to find the code description.
  • Not all NAACCR data items will have its list of categorical values within the ‘documentation’ key. Some NAACCR data items are non-categorical. Other NAACCR data items are what is called ‘site-specific’ (SSDI). SSDI means the data item’s categorical values are based on the anatomical site/topography being reported upon. For example:
    • NAACCR data item #1290 ‘RX SUMM--SURG PRIM SITE’: tracks the site-specific codes for the type of surgery to the primary site performed as part of the first course of treatment. This includes treatment given at all facilities as part of the first course of treatment. Here are the high-level grouping of site-specific surgery codes.
      • 00 None
      • 10-19 Site-specific code; tumor destruction
      • 20-80 Site-specific codes; resection
      • 90 Surgery, NOS
      • 98 Site specific codes; special
      • 99 Unknown
  • Return all NAACCR site-specific surgery codes table titles from this REST resource: https://api.seer.cancer.gov/rest/surgery/latest/tables. This will return an array of strings each string representing a site-specific surgery codes table title. Each table tile is a short hand for a group of anatomical ICDO site codes.
  • For each NAACCR site-specific surgery codes table title, call the REST resource (replacing ‘Breast’ with each NAACCR site-specific surgery code table title): https://api.seer.cancer.gov/rest/surgery/latest/table?title=Breast. This will return a hash with the following structure (the “row” key value can be seen in the separate file ‘row.json’): { "title": "Breast", "site_inclusions": "C500-C509", "hist_exclusions": "9727,9733,9741-9742,9764-9809,9832,9840-9931,9945-9946,9950-9967,9975-9992", "pre_note": "C500-C509
    (Except for M-9727, 9733, 9741-9742, 9764-9809, 9832, 9840-9931, 9945-9946, 9950-9967 and 9975-9992)", "row":[ {}, {}]}. The “site_inclusions” key details the range of ICDO topography/anatomical sites bound to this list of surgery codes. The “row” key is an array of hashes that represents the site-specific surgery code hierarchy. Some of the hashes in the “row” key are for line-break formatting and instructional text. Ignore all entries in the “row” key with a “line_break”: true key/value pair or that have a “code”:”” key/value pair. The hierarchal structure of the “row” key is based on the order of the entries. The “level” key can go from 0 to 3.
• Screen scrape the NAACCR EOD data SSDI data item possible values. A whole set of all SSDI NAACCR data items fall into the category ‘EOD Data’. See here a list of EOD schemas (anatomical site/histology groupings): https://staging.seer.cancer.gov/eod_public/list/1.4/. Unfortunately, it does not appear that the SEER API yet supports detailing the list of possible values for these data items. So we will need to scrape.
  • Visit https://staging.seer.cancer.gov/eod_public/list/1.4/
  • Click each “schema”.
  • Scrape the list of possible ‘Primary Site’ and ‘Histology’ associated with the “schema”.
  • For each row in the table labeled “Data Items”, if the “Metadata” column indicates “SSDI”, click on the link in the “Name” column.
  • On the page for the SSDI NAACCR data item, scrape the NAACCR data item and collect the possible values from the table with the headers “Code” and “Description”.
• Screen scrape the NAACCR TNM data SSDI data item possible values. A whole set of all SSDI NAACCR data items fall into the category ‘TNM Data’. See here a list of TNM schemas (anatomical site/histology groupings): https://staging.seer.cancer.gov/tnm/list/1.9/ . Unfortunately, it does not appear that the SEER API yet supports detailing the list of possible values for these data items. So we will need to scrape.
  • Visit https://staging.seer.cancer.gov/tnm/list/1.9/
  • Click each “schema”.
  • Scrape the list of possible ‘Primary Site’ and ‘Histology’ associated with the “schema”.
  • For each row in the table labeled “Main Data Items”, click on the link in the “Name” column.
  • On the page for the SSDI NAACCR data item, scrape the NAACCR data item and collect the possible values from the table with the header specific the SSDI data item. For example, 'Clinical T' and 'Clinical T Display’.

row.json
documentation.html