| OHDSI Home | Forums | Wiki | Github |
I’m using Usagi to map some custom procedure codes. While in Usagi, I noticed “pulmonary function test” maps to the Measurement domain. While “cardiac function test” and “auditory function test” map to the Procedure domain. All have a concept_class = Procedure. Please help me understand why a “pulmonary function test” is not a procedure.
Thanks,
Melanie
Hi, @MPhilofsky,
it’s a good question,
Basically, measurements are the evaluation procedures with exact (qualitative or quantitative) result,
if you take a look on the children of “Measurement of respiratory function” you will see such a concepts
Maximal voluntary ventilation measurement,
Peak expiratory flow measurement,
Lung residual volume measurement,
etc.
so all of them have numbers as a results - for example, about “1,200 mL” for a last test.
and looking on Cardiac functioning testing you’ll see the descendants:
Cardiac flow study imaging
Ballistocardiography
Cardiac electrophysiologic stimulation and recording study
etc.
so there are imaging, study, something that has not exact result,
that’s why these concepts are the procedures.
And custom procedure data-sets usually mix-up “our” measurements and procedures (so does SNOMED also :)).
so we usually filter not by domain_id but by concept_class_id =‘Procedure’ working on such a custom procedure mappings.
Thank you for explaining!
If I filter by concept_class_id = Procedure, then I would miss the CPT4 codes.
I didn’t want to map this procedure to a measurement, since it is truly a procedure in my source. So, I ended up googling “pulmonary function testing” and received back CPT4 code 94010. The concept_name = “Spirometry, including graphic record, total and timed vital capacity, expiratory flow rate measurement(s), with or without maximal voluntary ventilation”, so I see why Usagi didn’t return it as a possible match. Any tips or tricks to make my process more efficient would be appreciated 
We have a lot of custom data all over our source!
Thanks,
Melanie
Ouch!!! Melanie! You are violating the standard. Queries will expect the concept to be where they belong. Just because CPT4 has the word “procedure” in it doesn’t make all the codes procedures. Take 92531 “Spontaneous nystagmus, including gaze” - that’s hardly a procedure. They really are a mechanism to bill the CMS (or other payers), so whatever they decide is the right justification becomes a CPT4. For analytics, this is toxic, particularly if you are not intimately knowledgeable of the coding scheme. Think some poor analyst in Australia or Korea.
So, please please please follow the standard.
@Christian_Reich, you are right.
Well, here is another problem also:
Usagi doesn’t allow us to choose several attributes to filter by, I can’t filter the target concept by domain_id in (‘Measurement’, ‘Procedure’) or by Concept_class_id in (‘Procedure’, ‘CPT4’)
@schuemie, can you, please modify usagi, allowing these multi-attribute filters.
Help me understand where my logic is off @Christian_Reich
From my example above:
[quote=“MPhilofsky, post:3, topic:3371”]
CPT4 code 94010. The concept_name = “Spirometry, including graphic record, total and timed vital capacity, expiratory flow rate measurement(s), with or without maximal voluntary ventilation”
[/quote] the concept_id = 2314004, standard_concept = “S” and domain_id = “Procedure”. I thought I was doing the correct mapping. The concept in our source is a procedure, a pulmonary function test, and was administered to a patient. There is no result data associated with it, so the Measurement domain doesn’t seem appropriate. If my source concept had been a “Heart Function Test”, Usagi would map it to the Procedure domain (per my screen shot above).
Well, seems you are right,
such a “Measurement of respiratory function” concept describes is a “parental” hierarchical concept that includes the group of exact tests and measurements. So, actually, this concept can’t have any result itself, and should be turned into Procedure. In the next release will change the logic of SNOMED domain definition, turning these “parental” concepts in a procedures.
Such approach seems to be confusing for users. I suppose that all concepts within one hierarchy should predominantly
belong to the same domain.
Lets imagine some use case: user wants to define all patients with abnormal respiratory function test.
He assumes that all information about it should be stored in the observation table. And occurrence of ancestry concept with Procedure domain will embarrass researcher because due to our conventions concept_set should contain concepts within one domain.
In addition due to http://www.ohdsi.org/web/wiki/doku.php?id=documentation:cdm:measurement
Measurement domain could overlap with Observation, but not with Procedure.
@Dymshyts, @Christian_Reich your opinions about it?
@Friends:
I hear you, @Eldar. I had the same concern. We should debate this issue in the CDM WG. It’s not trivial.
