OHDSI Home | Forums | Wiki | Github

Dilemma of presenting surgery non-standard data to OMOP model

atlas

(Guy Livne) #1

Hi All,

I’m new in OMOP solution, and as the first use case to implement into the OMOP model I use surgery data.

As far as I learned, I use the Procedure_Occurrence for surgery start and end time, type and other information.

There is additional information that I thought of representing in an external table, like: Time of anesthesia, time of first cut, type of anesthesia, also information during plan phase of the surgery like surgery type, planned date and time, etc.

The general question is if it recommended using external ‘subject dedicate tables’ and if those tables can be representing in ATHNA and ATLAS applications?

Thanks in advance,

Guy


(Christian Reich) #2

@guy_livne:

Well, right now there is no end datetime. If you have that kind of granularity you should submit an issue so we can consider adding it.

Currently, that is it’s own procedure record. Assuming there is only one surgery per day no special linkage between anesthesia and surgery is needed. If you think this is too much of a simplification let us know in the same issue.

Same.

We don’t have that. If you have detailed information like this also bring it up.

We generally don’t store plans, only actions. Again, if you have a use case bring it up and we should think how to support it.


(Antoine Lamer) #3

Hi @guy_livne, Hi @Christian_Reich

I face the same difficulties with integrating anesthesia procedure:
An anesthesia procedure is a procedure itself, linked to one or more surgical procedures.
In one day there may have one or more anesthesia procedure (as a patient may be re-operated).

During the anesthesia procedure, some events occurred : incision, induction, end of surgery, end of anesthesia, intubation, extubation, liver clamping … all these events occured around the anesthesia/surgical procedure, and their timings is important in the way they impact analyses of measurements.

@guy_livne perhaps we could continue to explore other aspects of operative events not taken into account for now ?


(Michael Gurley) #4

@AntoineLamer @guy_livne

Hello, in the OMOP Oncology Extension (which is still in the DEV branch validation phase), we have introduced the idea that an Oncology Diagnosis (CONDITION_OCCURRENCE or EPISODE) or an Oncology Treatment (PROCEDURE_OCCURRENCE or EPISODE) can be "modified’ with characteristics within the MEASUREMENT table via the addition of two new fields:

measurement_of_field_concept_id
measurement_of_event_id

See data model here

Sounds like these kinds of properties you want to analyze about surgeries could unambiguously be related to entries in the PROCEDURE_OCCURRENCE table via the new fields in the MEASUREMENT table.

As far as associating two or more surgical procedures together to address “your
anesthesia procedure is a procedure itself, linked to one or more surgical procedures.”, I would suggest we add a procedure_occurrence_parent_id field to PROCEDURE_OCCURRENCE table that would allow for the main surgical procedure be the parent of its child surgical procedures.

Most EHR surgical scheduling data models that I have worked with have the concept of a “primary” surgical procedure that can be linked to one or more subsidiary non-primary surgical procedures. This is often done with a 'Surgical Case" construct.

To me this is an example of where OMOP’s distaste for representing “connections” between clinical events gets in the way of many common sense use cases. If these connections live in the real world data, I don’t know why we torture ourselves by dropping the connections when we import the atomic clinical events into a Common Data Model. Forcing us to rely on dubious “on the same date” logic.


(Antoine Lamer) #5

Hi Michael,

I am very interested in your proposition. We could model episode of surgery, anesthesia, but also the episode between the induction of anesthesia and the start of surgery which is use to study hypotension (following the administration of hypnotics).
Moreover, episode and episode event could also by used to modelize episode of adverse events based on measurement.
Example : episode of hypotension detected with arterial pressure measurement.hypotension


(Rimma Belenkaya) #6

Episode table is intended to store meaningful aggregate of multiple events representing disease or treatment episodes. For example, you may store a surgery (surgical case) in the Episode table while storing individual procedures, including anesthesia, related to this surgery in Procedure_Occurrence. Links between individual procedures and the episode of surgery would be stored in Episode_Event.

However, I don’t think we should be using Episode module for storing timed components of surgery or other procedures. I don’t think that in the CDM now, there is an appropriate construct for representing procedure components. If there is a use case that requires analysis of procedure components, I suggest creating a table similar to Visit_Detail.


(Antoine Lamer) #7

Hi Rimma,

Thank you for these clarifications. Indeed, a table similar to visit_detail could be useful.

In the case of the surgery in the episode table, you mean not only the surgical act (stored in procedure_occurrence) but also the whole stay ? or recovery period ?


t