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?
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.
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 ?
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:
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.
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.
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.
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 ?
From a clinical point of view, the anesthesia and surgery are not only acts linked to each other (as it may be for billing purpose). They’re more like a succession of events (entry to the operating room, start of monitoring, anesthesia induction, airway mangement, etc …) which can be used in a second step to compute durations.
All the duration (induction, maintenance, emergence, recovery room, anesthesia) may be used in analytics, mainly as adjustment factor or for detecting adverse events (as hypotension).
Here are two examples:
Hypotension may be detected between anesthetic induction and surgical incision or between induction and extubation, depending on the question being addressed.
We may want to explore the evolution of heart rate around the administration of atropine (in the operation theatre), with sliding window around the administration date.
To address these issues, proposition of @mgurley is interesting if episode_start_date and episode_end_date may store all the events detailed in the first figure.
Surgery and anesthesia time information are stored in Observation table. Each time point is one record. Some of the concept_ids are:
40483133
Start time of procedure
40482217
Completion time of procedure
4171540
Anesthesia preparation time
4161949
Anesthesia start time
4160029
Anesthesia finish time
40480482
Time of induction of anesthesia
40483093
Time of establishment of adequate anesthesia
40483530
Time of discharge from post anesthesia care unit
40481318
Time of patient arrival to location for anesthesia
40482694
Time of patient arrival in post anesthesia care location
40483565
Time ready for discharge from post anesthesia care unit
40483182
Time of arrival of anesthesia care provider to anesthetizing location
After putting these information in Observation table, they will be linked up with the actual surgery in Procedure table via Fact_Relationship table. I have provided an example in here.
Thank you again for your help @QI_omop. Indeed, these concepts correspond to what I need. Moreover, concept 38000280 Observation recorded from EHR match with observation_type_concept_id.
In a second step, if we detected hypotension based measurements and period (in Observation), could we store the result in Episode table ? For example, in my first figure, the episode 1 between T1 and T2.
One last question, do we prefer LOINC or SNOMED concepts ? as many are similar.
In a second step, if we detected hypotension based measurements and period (in Observation), could we store the result in Episode table ? For example, in my first figure, the episode 1 between T1 and T2.
There is CDM Working Group discussing question like this. If you think you have a strong case of using Episode table, you may want to propose it in the working group meeting.
One last question, do we prefer LOINC or SNOMED concepts ? as many are similar.
For condition, SNOMED is preferred and is the standard. For lab test, LOINC is used as standard in most cases.
