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