OHDSI Home | Forums | Wiki | Github

Surgical Expertise

Implementers
#1

Had a conversation today about if it is possible to store surgical expertise in the CDM. This warrants being stored in the CDM as there are important research questions around the impact expertise has on the short-term and long-term outcomes for a patient. Surgical experience also changes over time so while associated to the provider isn’t a static item to store in the PROVIDER table.

Let’s use an example:
For a given surgery, Dr. P. Ryan is the Primary Surgeon who is a certified surgeon in the area they are working and Dr. P. Rijnbeek is the Assistant Surgeon who is a surgeon in training.

PROVIDER
Dr. P. Ryan and Dr. P. Rijnbeek will both have records in this table.

PROCEDURE_OCCURRENCE
A record of the specific procedure being performed, this is linked to a VISIT_OCCURRENCE. You can list the PRIMARY surgeon on the PROCEDURE if you want as well.

VISIT_DETAIL
One record for each Surgeon involved.

VISIT_OCCURRENCE
This ties together 2 VISIT_DETAIL records. You could list the PRIMARY surgeon on the VISIT_OCCURRENCE if needed.

OBSERVATION
We store the PRIMARY versus SECONDARY surgeon bit in the OBSERVATION_CONCEPT_ID. Then in the VALUE_AS_CONCEPT_ID / VALUE_AS_STRING we can store the expertise at the time of the surgery. This record is tied to the surgeon via the VISIT_DETAIL table.

This isn’t necessarily graceful but you could get from a procedure, through visit, you could connect up the provider to their specialty. I just wanted to put this out there to see if people had better ideas.

Tagging my friends @sbicty, @gregk, @Alexdavv, @Alexandra_Orlova, @Albert_Prats, @clairblacketer

3 Likes
#2

this is a very important topic, and one that is fundamental for both surgical and medical device epidemiology
other than the name if the surgeons, I think the proposal above should work. can we give it a try vs source data eg in HES or CUIMC data? @jenniferlane @mattspotnitz @Albert_Prats @edburn

#3

I agree with @Daniel_Prieto and I think this is a great solution. My only suggestion would be to write a couple queries that will retrieve this information once implemented to demonstrate the correct approach.

#4

Here is a lame query that at least connects all this information together. Then you would just filter to what you need (e.g. provider, procedure)

SELECT *
FROM PROCEDURE_OCCURRENCE po
	JOIN VISIT_OCCURRENCE vo
		ON vo.PERSON_ID = po.PERSON_ID
		AND vo.VISIT_OCCURRENCE_ID = po.VISIT_OCCURRENCE_ID
	JOIN VISIT_DETAIL vd
		ON vd.VISIT_OCCURRENCE_ID = po.VISIT_OCCURRENCE_ID
	JOIN PROVIDER p
		ON p.PROVIDER_ID = vd.PROVIDER_ID
	JOIN OBSERVATION o
		ON o.PERSON_ID = po.PERSON_ID
		AND o.VISIT_OCCURRENCE_ID = po.VISIT_OCCURRENCE_ID
#5

Given there isn’t a good way to create care teams in OMOP and there hasn’t been a use case, this seems okay, but I’m a bit hesitant about the multiple visit_detail rows. I know it’s listed in the conventions to have a new row per provider or location, but then the visit_details table becomes extremely large. We have been only using the visit_details table when the patient location changes and have not figured out what to do about provider. I guess that should be debated in THEMIS (or the CDM group).

One point on the observation reference - I think it should link to the visit_details as opposed to visit_occurrence b/c we would want primary vs secondary for the surgeon and the visit could have started as an ED visit or there could have been multiple surgeries during a visit. I supposed in this case we would have to use the fact_relationship table. I don’t know v6 that well, but maybe this could be handled better there?

1 Like
#6

Erica I’m so glad you are pushing solutions for this!

I think you are talking about a couple of things at once. I tease some of them out with my 2 cents below.

Attribution: Primary and secondary surgeon in your example.
We badly need a more accurate and detailed set of conventions for assigning attribution to clinicians in general, not just surgeons. In addition to the use cases mentioned, it is important for any research that tries to link a measure of care quality to related outcomes. Attribution is tough in many settings because a senior physician such an attending will sign off on order decisions and procedures that the resident under him/her has performed. So the clinician of record is responsible for review and approval rather than having made or done the thing we see. Distinguishing this would be useful. Patients are often treated by teams rather than a single physician and the attribution of all care to an individual is misleading. An algorithm that explodes single physicians into the team of clinician’s providing care would be also be very useful because it would not only help to get attribution right, it would allow the study of teams as a unit of performance.

Expertise: What do you have in mind when you say store expertise at the time of surgery? There are at least four ways “expertise” might be justifiably defined. Tenure (how long the person has been practicing as inferred from data of MD degree from HR dept records; Volume - derived value of number of cases in the same category over the previous year; Training - where the person was trained in the relevant medical procedure - derived from HR; Success - complex case-mix adjusted derivation of successful outcomes. The last definition is best deserving of the name expertise. The others are pretty weak proxies. Volume is next best. But there is a lot of variation in performance among physicians with the same volume. Experience does not equal expertise. The most useful concept for research is going to be one that most directly captures performance quality - Success. But getting that calculation right and doing so in a standard way that generalizes across OHDSI data sources is going to be hard. I’m up for it though if others are. The safest way to define it might be very sub-optimal but workable. Use the volume at the clinic as a proxy for the physician. That gets around the need for proper attribution at the clinician level. It partly accounts for the fact that other staff and resources contribute to the quality of surgical performance. It also is in keeping with research conventions that examine differences in outcome at “high volume” vs. “low volume” clinics. That may be where your original use case came from.

Learning: You said experience changes over time. I think you were using experience as a proxy for expertise There. This is one of my absolute favorite topics. I’m a psychologist - we study learning. I’d love to be able to use OHDSI tools to implement study ideas I’ve been working on for years. I won’t detail those here, but enabling the analysis of learning (medical skill acquisition) over time would be huge. Doing so would require not only finding a place to put the data, but conventions/algorithms for proper attribution of care to physicians, and for capturing or deriving a clear operational (bad surgery pun alert) definition of what expertise means.

1 Like
#7

I like the idea of using visit_detail table!
I have only one concern: if one visit_occurrence_id will be linked to more than one procedure (if a patient had 2 procedures per day), it might be difficult to understand which procedure observations are related to.
So to solve it we can make duplicates in procedure_occurrence table (record per surgeon) and link them to visit_detail records or we can link observations with procedure_occurrence record directly via fact_relationship table (CDMv5.3) / observation_event_id, obs_event_field_concept_id (CDMv6.0).

1 Like
#8

Why is a contorted solution that fits within the CDM thought to be inherently better then to create a solution that may require additional columns or tables? Neither solution is of any use outside of the small circle of friends that understand the intricacies of the proposed scheme. A solution that better models the use case is to a add a many to many table between the procedure and the provider tables. This new table can have columns for who was the primary or secondary and their level of expertise. The procedure date will fix the provider’s level of expertise in time. The query to get the providers involved and their level of expertise will be less complicated.

1 Like
#9

Friends: What’s the use case? Estimation of outcome association between individual providers and outcomes? Primary or secondary provider cohorts and outcomes?

#10

Not sure if that’s the original use case, but it would be interesting to see if controlling for provider changes the results. There are speculations that surgeon influences outcomes more than choice of operation, patient state, etc.

#11

@Christian_Reich, We are in the middle of conducting research to try and predict the surgery time length, some of the attributes for the research are team members’ expertise and experience which include primary surgeon assistant surgeon, primary nurse, anesthetic etc.
We used fact_relationship to connect all team members to the surgery procedure, I think @DTorok suggestion for an additional table that can hold the duty and expertise in the event is a good idea.

#12

@guy_livne: Sounds good. And you have stored the “role” in the observation?

If it works for you - fine. The problem is standardization (who would know you put that information in there) and patient-centricity. Doing research on the provider is provider-centric research. Nothing wrong. The OMOP CDM is not well designed for that.

t