Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Oncology/Episode of Care Combined Proposal #239

Open
clairblacketer opened this issue Nov 16, 2018 · 8 comments

Comments

Projects
None yet
7 participants
@clairblacketer
Copy link
Contributor

commented Nov 16, 2018

On 11/15/2018 @rimusia and @mgurley walked us through the revised oncology/episode of care proposal that now includes oncology diagnoses as well. The slides are below:

Oncology CDM Proposal 2018-11-15.pdf

Previous discussions of this topic were had on issues #163 and #199.

@vojtechhuser

This comment has been minimized.

Copy link
Collaborator

commented Nov 16, 2018

If a full list of modifiers could be provided (from representative source data), that would be helpful (tumor size, lymp node invasion). Do all of them have LOINC or other codes or new concepts are needed?

@mgurley

This comment has been minimized.

Copy link

commented Nov 16, 2018

@vojtechhuser
The two main source of oncology diagnosis modifiers that we will be pulling from our the Nebraska Lexicon (which formalizes the CAP cancer checklists) and NAACCR. To see the full breadth of modifiers that these two sources cover, see the following:

You will see that for both standards the list of possible modifier are scoped/namespaced by anatomic site.

Nebraska Lexicon/CAP covers the data points that pathologists capture on pathology reports to diagnose patients with cancer. NAACCR covers how tumor registries capture those same data points to fulfill government reporting/surveillance mandates.
Let me know if this answers your question.

@don-torok

This comment has been minimized.

Copy link

commented Nov 16, 2018

The episode_event table is an ugly table. Can you provide a sample of how episode_event will be queried. I am trying to understand why it is superior to a table like (event_id, domain_id, event_id).

@mgurley

This comment has been minimized.

Copy link

commented Nov 17, 2018

@vojtechhuser Sorry I did not see the second part of your question. No, there are not SNOMED/LOINC codes for all the possible data points. Or at least not yet. The Nebraska Lexicon project mission is exactly that. Actually, the Nebraska Lexicon is slated to be included within SNOMED. Where existing concepts are present within SNOMED to reuse them and where they are missing to add them. In total, to enable the representation within a standardized vocabulary (SNOMED) the oncology diagnostic modifiers (question/answer attribute/value) that are used in clinical practice. The Nebraska Lexicon/SNOMED has completed a couple anatomic sites and have many near completion. In the interim, while we are waiting for the Nebraska Lexicon/SNOMED to complete all anatomic sites, the idea is to promote the NAACCR diagnosis modifier concepts for the anatomic sites not yet complete as standard concepts. For those anatomic sites that Nebraska/SNOMED has completed we would use Nebraska/SNOMED as the standardized concepts and create maps from NAACCR concepts to Nebraska/SNOMED concepts.

@cgreich

This comment has been minimized.

Copy link
Contributor

commented Nov 18, 2018

The episode_event table is an ugly table. Can you provide a sample of how episode_event will be queried. I am trying to understand why it is superior to a table like (event_id, domain_id, event_id).

Because linking through the domain_id will be abolished in V6. Reason: Ultra slow, because you have to use a complex case when then end construct, instead of RDBS-type foreign keys.

@rimusia

This comment has been minimized.

Copy link
Collaborator

commented Dec 4, 2018

The updated version of the proposal reflects changes to the EPISODE_EVENT structure and includes query samples:
Oncology CDM Proposal 2018-12-02.pdf

@dimshitc

This comment has been minimized.

Copy link

commented Dec 13, 2018

Was talking to @gowthamrao
He suggests to use event_fieldconcept_id instead of eventtable_concept_id
in the EPISODE_EVENT Table
so instead of, let's say, condition_occurrence we'll have condition_occurrence.condition_occurrence_id that explecitly indicates the field the EPISODE_EVENT is related to.
Actually, it makes sense to me. @rimusia , @mgurley , what do you think?

@clairblacketer

This comment has been minimized.

Copy link
Contributor Author

commented Apr 25, 2019

This proposal was added to the dev branch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.