OHDSI Home | Forums | Wiki | Github

Concept Type consolidation - please take a look

CDM Builders
#21

Maybe this is limited to conditions but if not:

What about provenance and drugs

In Sentinel and PCORNet there are 2 tables :order table and dispensation table. OMOP seems to resist that.

This drug exposure comes from PHR (patient recording taking this)

This drug exposure comes from EHR order entry system.
this …comes from pharmacy dispensation claims.

What about provenance of measurements.

This measurement comes from lab

This measurement is inferred from CPT4 code (and has no value)

Accelerated lab should be child of lab result. How is it different from Urgent?

Ability to order you file by type is key
image

Do you want comments in the google spreadsheet? (row specific comments?)

visit types
Also, for dream challenge, I wanted all inpatient visit subtypes and it was quite hard to see that in the dictionary. Atlas offeres concepts from NUCC vocabulary. (which is not even listed on vocab github as formal source). What is NUCC?

image
image1666×689 51.9 KB

1 Like
#22

@Christian_Reich: is the thinking that “EHR administration record” is intended to be a bucket for all those loosey goosey Epic-encounters that people regularly struggle to figure out where to go? (e.g. encounters that are person-centric but are really phone calls, insurance cards being updated, etc etc)

Or am I too aspirational? #askingforafriend

#23

Not sure what OMOP “resists” or “likes”. :slight_smile: But you got “EHR order” and “Pharmacy claim” in there.

“Lab”

CPT4 is not a provenance. It’s a code. The provenance is still whereever you picked up the CPT4, which is a claim or some place in an EHR. The fact that it was coded as a CPT4 is evident from the SOURCE_CONCEPT_ID.

Somebody who knows this should tell me if “urgent” or “accelerated” is better. Will add the childhood.

And do you think this is not the case?

Whereever you like it.

Are you talking about Visit Type Concepts (which are the provenance of where you got the information about a visit from) or Visit Concepts?

That’s the National Uniform Claim Committee’s Health Care Provider Taxonomy Code Set. There is no script to bring it in. It’s a CSV file that was reformated and loaded.

You got it.

#24

We create a very well specified convention for people to create a fake condition record so they can give it a condition_type_concept_id for the provenance of the death record, correct?

I think it may be better than adding another field. However, it’s a very low pain point at this time because of the low adoption rate of V6.

Thoughts from other folks?

#25

No, this isn’t correct. Administration is actually a verb, not a noun in this context. It’s the administration of a drug. Thank you for pointing this out. We should clarify by renaming “EHR administration record” to “EHR drug administration record”.

FYI @Christian_Reich look at the domain_id for “EHR administration record”

#26

We had/have drug_type_concept_ids for ordered/prescription written, administered, dispensed, and patient reported. Along with the claim type_concept_ids for pharmacy, medical, etc.

#27

Ah! You are good.

Don*t want “EHR Drug Administration record” because it has to be Domain-independent, and the administration could be a procedure or a device.

What should we call these things?

#28

Is the plan that column D concept will become standard and column A concept will lose the standard status?

Also,
concepts
32426|NLP derived (Drug Type)
32424|NLP derived (Condition Type)
will become one concept?

What vocabulary_id it will be under? (what if fits into multiple)

Achilles Heel checking for permissible values for type concepts was relying on some vocabulary logic. Can you describe this logic for valid visit types under this new proposal?

please freeze the top row in the google sheet!

#29

Exactly.

Exactly, because we want to remove the Domain-specificity. It makes little sense.

New vocabulary_id=“Type”. The vocabulary_name in the VOCABULARY table will then contain the proper indication that this is really provenance.

Visit Types no longer exists. They become Types. What you are talking are Visit Concepts. That’s all those Inpatient Visits, Outpatient Visits, etc. They are different vocabulary_ids, but Domain_id=‘Visit’.

#30

Ok, I gave it some thought. And I think we should leave it as “EHR Drug Administration record” because administration is only needed to distinguish the provenance of administered Drugs from dispensed Drugs. It’s not applicable in other domains. Let me know your thoughts, @Christian_Reich.

Devices: These may be administered or dispensed to a Person. However, the type of Device informs us if it was administered or dispensed. Examples: Pacemakers are implanted (aka administered) by a Provider, they are not dispensed for the Person to take home and self administer. Blood sugar monitoring devices are given (aka dispensed) to a Person for them to use as directed. You don’t administer a blood sugar monitoring device. You give the device to the Person for them to use. It’s inherent. Are there Devices that can be administered and dispensed? Is there a use case to know the difference?

Procedures: There aren’t dispensed or administered Procedures. The Person either received/underwent a Procedure, reported a past procedure or it was ordered.

Administered and dispensed type concepts are not applicable for Conditions, Measurements, Specimens, Notes, Deaths, Visits, Visit Details, or Observations.

#31

No, you could have the same logic with devices.

Not necessarily. For example, glucose sticks can be administered in the office or dispensed for self-administration. We see those data all the time.

I agree, not all Types will be applicable to all Domains. But who cares. The current situation is worse, because we have these endless duplications and triplications.

#32

Hi all!
I really like the idea of concept type consolidation and would like to know what is the current status? Do you plan to release it soon?

I would also like to bring one more concept which indicates provenance and currently is missing “health information exchange”. Could you please add it to your consolidated list for release?

Many thanks!
Tatiana

1 Like
#33

I suppose we’ll even add it to the standad vocabulary now, because it might take a while to have this consolidated list. And also you will not miss this concept, because it will be aleady there.

1 Like
#34

Does the ‘Survey’ type mean that information is always patient self-reported? If so, maybe we need to set a ‘Person self-report’ ancestor for Survey type?
If Survey might be populated by medical staff based on a patient medical charts or something else, do we need to distinguish which records are patient self-reported and which are not?

#35

Friends:

Trying to close this out now. Has been sitting and maturing for a good chunk of time. See the spreadsheet. I added the Condition Status Concepts with their mini-hierarchy. It’s explained here: Primary dx vs Secondary dx. The way it works is that what used to be e.g. concept “Carrier claim detail - 10th position” now is split up into the Type Concept “Professional claim detail” having the parent “Professional claim” and the grandparent “Claim”, and a Condition Status Concept “Secondary diagnosis”.

You got it.

Added as well.

Let’s do a final round of review and then push it out.

2 Likes
#36

Reviewed and approved :slight_smile:

#37

I’m a bit lost.
So you added 2 types (‘Patient filled survey’, ‘Healthcare professional filled survey’) instead of one ‘patient self-reported’ ancestor.

What does ‘Healthcare professional filled survey’ actually mean? That Survey is filled based on more reliable info than patient responses (e.g. patient medical chart, lab results, etc.) or that Survey was filled by Healthcare professional as assistance for a patient?
If latter then for that purpose we can use ASSISTED_CONCEPT_ID from SURVEY_CONDUCT table

#38

@Alexandra_Orlova:

You are lost? :slight_smile: I thought you wanted to split Survey into the two kinds based on who filled them out. They will have different qualities, so the requests made sense.

“Person self-report” is about anything self-reported, not just the surveys. But not all surveys are patient reported.

What do you think?

Remote (telemetry) BP readings
#39

e.g. Bionank contains a verbal interview with patient. The interviewer is a trained member of the medical staff and s/he should choose the correct cancer-code or other illness based on the patient responses.
So technically survey is filled by a healthcare professional, but it’s still patient self-reported condition.

I am not very familiar with surveys and was asking whether or not it is possible that a survey is filled by a healthcare professional not based on patient responses, but based on more reliable info (medical charts, etc.)?
If the latter is not possible, then I think we don’t need to split into 2 types because to highlight that a Survey was technically filled by healthcare professional we can use ASSISTED_CONCEPT_ID from SURVEY_CONDUCT table
If the latter is possible, then yes, we probably need to split it:

  1. ‘Survey: patient self-reported’ - patient self-reported (even if a survey is technically filled by healthcare professional)
  2. ‘Survey: healthcare professional reported’ - info is not from a patient (from charts, lab results, etc.) and survey is filled by healthcare professional
#40

@Alexandra_Orlova:

Yeah. Look. All information about symptoms and life circumstances is coming from the patient no matter what. All information obtained in the healthcare system (lab tests, imaging, diagnoses etc.) is coming from the healthcare system. So, that is not relevant.

What’s relevant is who records. “Self-reported” actually means self-reported. No healthcare professional checks the answer and asks back (“you really cannot sleep at all during the night?”). HCP reported means the doctor or nurse or interview specialist does it.

So: Self-reported survey is a subset of Self-reporting and of Survey. HCP filled survey is just a subset of Survey.

Works?

Type concepts, mismatch between Rabbit in a Hat and Athena
t