OHDSI Home | Forums | Wiki | Github

Procedure Status


(Maxim Moinat) #1

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


(Christian Reich) #2

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


(Maxim Moinat) #3

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.
https://biobank.ndph.ox.ac.uk/ukb/exinfo.cgi?src=HESupdate_2019_09

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?


(Spiros Denaxas) #4

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.


(Qi Yang) #5

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


(Christian Reich) #6

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?”


(Mark Danese) #7

@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.


(Melanie Philofsky) #8

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.


t