OHDSI Home | Forums | Wiki | Github

Concept Type consolidation - please take a look

CDM Builders
#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
#41

Got it. Thanks!

#42

Thought it would be helpful to include the new Domain-free concept_id along with their names. See

#43

If you are unfortunate and still working with vocabulary 4.5 there is an error in implementation. All the concepts in columns A and B have been dropped from the concept table in release ‘OMOP Vocabulary v4.5 28-AUG-20’.

#44

@Christian_Reich,

Now that the new type concept_ids are out for use, I’m circling back to type_concept_ids for Death data.

There are only two type_concept_ids specific to death:

32815 = Death Certificate
32885 = US Social Security Death Master File

For CDM v6 the cause of death is in the Condition table. In order to identify the cause of death from other conditions, we need an appropriate type concept_id. 38003569 = ‘EHR record patient status “Deceased”’, was a good one. However, it’s been deprecated. Also, Registry data will have Death data and is commonly used to enhance EHR data. So, a Registry for death type_concept_ids is needed. This will also help out Colorado with their v5.3.1 OMOP :slight_smile:

#45

Got it. So:

EHR deceased status record - child of EHR
Registry death record - child of Registry

Like that?

#46

Perfect! Thanks!

Condition_occurrence, Death diagnoses
#47

Actually, I repeal.

The identity of a Condition is in the Condition Status. There are a bunch of those assigned to cause of death. And then use EHR and Registry for the provenance. No need for any new concepts.

Thoughts?

#48

Hi all, could you clarify the usage of new consolidated type concepts for Clinical Trials datasets.
In many CT datasets, the provenance of data is only a CRF. Does this mean 32809 - Case Report Form should be used for conditions, observations, measurements, etc. or 32817 - EHR is a better option?

#49

I found my way to this thread after being confused by the various “Type” vocabularies still present in Athena. I am grateful that these Type Concepts were cleaned up and consolidated!

I have a question about the right concept to use for vital signs. In the inpatient setting, these are typically recorded by the patient’s nurse on a flowsheet, but I do not find any “EHR flowsheet” concept. The concept “EHR nursing report” (Concept ID 32832) doesn’t sound like a proper substitute. What are others using?

What about vital signs taken by a nurse in the context of an outpatient office visit, before the patient sees the clinician? “EHR physical examination” (Concept ID 32836) could be used, but a physician may draw a distinction between these “rooming” vital signs (for example, BP via automated cuff) and vital signs taken by the physician (manually, because the automated cuff readings are sometimes inaccurate).

#50

The condition_status is good.

What’s the difference between concept_id = 32891 ‘Cause of Death’ and 32895 ‘Death diagnosis’?

#51

Not sure I understand the question. 32809 “Case Report Form” is the Type if that’s where the data are collected from. If they are collected from the EHR than 32817 is the answer. The Types are used to indicate to analytical use cases if they want to prefer or suppress certain sources of information.

#52

Happy to hear that. :slight_smile:

I would take actual analytical use cases to determine if another Type is needed. Do you have one? Would you only want data from the flowsheet? Is your task to find out if nurse or physician measured vital signs result in different outcomes? @MPhilofsky? Any opinion?

t