OHDSI Home | Forums | Wiki | Github

Procedure Status

I want to argue for a procedure_status_concept_id .

The condition table contains a condition_status_concept_id to store e.g. whether a condition is a primary or secondary diagnosis. In multiple sources we also see statuses for procedures, indicating a main or secondary operation.

Before the new type concept consolidation, this primary/secondary distinction could be made using the type concepts. With the newest changes, it is not possible anymore to use standard concepts to add information about the status of the procedure.

Also posted as a CommonDataModel issue

Is there such a thing as a “secondary procedure”, @MaximMoinat? What would that be?

Good question. I looked in the source dictionary (for HES oper to be precise), and could only find that there is a distinction between main and secondary operations.

The operation/procedure codes are similarly now all contained in a single table hesin_oper, with main operations given level=1 and secondary operations level=2.

All I can think of is that the main operation is the reason for e.g. the surgery, and all other operations performed are labeled as secondary.
@spiros Is there an analytical use case for this level of operation?

I think there are two main uses for the “secondary procedure” fields.

Firstly, it’s used to record information that supplements the main procedure using OPCS4 terms from chapters Y and Z which describe the methods, sites or laterality of a procedure. This is also evident if you look at the frequency distribution of terms recorded as secondary (primary procedures contain no Y/Z terms)

Secondly, it looks like that field might also be used to record information on complementary/incidental procedures occurring during the primary procedure and/or procedures which are often commonly performed together.

1 Like

The Procedure_Occurrence table has a column called modifier_concept_id. The purpose of this column is to provide additional information about the procedure, such as methods, sites or laterality. The accepted concepts are here

Modifiers: We want to get rid of the modifiers. They are either part of the procedure, or a procedure of their own.
Complementary/incidental procedures: What’s the use case? Are you planning on something like “Research procedures that were incidental, e.g. not planned and were only considered once the patient was in the hospital?”

@Christian_Reich I know you know this already, but I wanted to point this out for others who have not seen this before. In US claims data, modifiers serve many purposes. They can indicate that someone assisted another provider so if someone isn’t careful and ignores the modifier they will double count the same procedure. They can contain laterality, lab values, wastage information for medications, and lots of other things. It is an admirable goal to get rid of them, but it is a lot of work.

1 Like

We do? Who is included in the “we”? Per previous discussion, modifiers need to be cleaned up and placed in the appropriate tables.

As @Mark_Danese pointed out above, we have the use cases.

1 Like

The issue was addressed here. Please take a look.

@Alexdavv Am I correct in summarising that you consider this modifier-use-case #5 "Indication of distinct procedure/encounter vs part of other event." and we will not standardise this as it has limited value for observational research?

I would be totally fine with that assessment, we just have to make this a formal convention (something for when the Themis WG is restarted).