OHDSI Home | Forums | Wiki | Github

Representing laterality + general questions about post-coordination

Dear all,

I’m currently working on mapping for ophthalmology data. After reading documentation and forum posts, I still have some questions I’d like to clarify regarding use of post-coordination within OMOP clinical data tables.

The problem of adding additional information to concept records appears to have arisen in multiple contexts. For example, this forum discussion highlights some examples where post-coordination, in the form of modifiers, is needed for storage of procedure information, such as “left side”/“right side” in cataract surgery. Other examples of discussion: a; b; c.

I am unsure about the accepted methods (if any) for entering data with multiple linked elements. Example problem instances, with my questions for them, are:

  1. Data elements where one qualifier needed. Laterality of a finding is an important example in ophthalmology:
    - For observations, such as “History of retinoblastoma” (46273446), it would be possible to use the qualifier “Left” (4300877). Would this be accepted usage?
    - For measurements, such as Keratometry flat power (44783564) or conditions there is no qualifier field. How would laterality be encoded here?
  2. Instances where multiple qualifiers needed, for example: measurement + laterality + procedure/device used. This information could be relevant for investigating performance of a particular method for keratometry. Would something like this be recorded in the fact relationship table, or just excluded?

Advice on best strategies for the above problems would be much appreciated.

I also have a query about the general model of data types within the CDM (ie table column definitions). Do we enforce, for example, that all clinical data are modelled as unlinked single-variable occurrences? Clearly there’s some data for which this would be suboptimal (paired samples, for example) and some for which it would be prohibitive (pixel data, sequence data). From a newcomers perspective, such a characterization seems fairly key. If it isn’t already done, perhaps such characterization could help add clarity for ETL designers, or facilitate the CDM’s qualities as an information representation.

Apologies for the multiple-question post, hope it’s acceptable/useful!

(@Christian_Reich I noticed your input on a lot of the topics linked - your thoughts on the above would be much appreciated!)

@willhalfpenny:

Yeah, this keeps popping up. And as long as we haven’t created a solution it will keep doing so. The issue actually is simple:

The OMOP model in it’s nature allows for recording of medical facts. Each fact has a time stamp when it happened and a fully normalized way to represent what that fact is. In other words, everything is represented by a concept, and the concept (reference really) table is the Standardized OMOP Vocabularies. This allows for complete separation of analytics from the way the data are organized, and therefore remote analytics in a network.

That means that all facts need a concept. The concept has to have all relevant attributes pre-coordinated. The question is: What are relevant attributes?

The answer is NOT everything that the source data have. The notion is that we need to by all means preserve every single detail, otherwise we perish. That is the attic use case (put things on the attic because you might need them later, but you don’t know why yet).

The answer actually is what is needed for answering a scientific question, the analytical use case. Is right and left eye needed in analytical use cases? Maybe. You tell me. My hunch is no, because we are not treating individual patients (where it is highly relevant which eye needs treatment). We are “treating” populations, and unless there is a systematic difference between the eyes (I am not aware of that) it won’t matter. So, try the thought experiment, drop the left/right information and decide if your research question still stands.

If you really need it, we need to create those pre-coordinated concepts. Put in a Github issue into the Vocab system or tell us here.

1 Like

It isn’t uncommon in ophthalmology research to do an analysis of eyes in addition to an analysis of people. Things like visual acuity are captured for each eye and it is important to keep longitudinal measures for each eye straight to look at temporal trends. A couple of examples below.

Hi all,

I am brand new to OHDSI, but I come from an ophthalmic research background.

I can concur with what @Mark_Danese mentioned regarding the significance of knowing and tracking laterality (for certain research questions). It can also be necessary when one condition, such as age-related macular degeneration, might progress at different rates in each eye within the same patient, or if each eye undergoes procedure(s) at different times, etc.

I have also been thinking about the mapping of laterality within the CDM, particularly in the context of primary open-angle glaucoma (POAG). I have submitted an abstract on POAG phenotype algorithms to the OHDSI 2022 Symposium, and part of what I am trying to explore within my analyses is how to more accurately map laterality from non-standard vocabularies, such as ICD-10, to standard SNOMED concepts. I will put in a specific Github issue regarding this recommendation shortly.

I imagine improving the laterality mapping for other common ocular conditions would also be of use? Has anyone explored this before?

I also plan on connecting with the leads of the Eye Care & Vision Research workgroup, @Kerry_Goetz and Sally Baxter regarding this topic.

I believe that for eye care, the specific eye is very important and needed for all clinically relevant ophthalmology use cases. The vast majority of ophthalmic medications are eyedrops that are applied to a single eye or both eyes. Similarly, surgeries are also performed only on one eye at a time. And this is because diseases often progress differently between the patient’s two eyes.

So, if someone is trying to answer correlation questions about how eye diseases affected a systemic illness, then perhaps it doesn’t matter whether a left or right eye was used for the measurement (hopefully both were measured and rationally combined.) But if the question is about whether a systemic illness (or med or exposure) affected a patient’s ophthalmic disease and vision then the laterality is vitally important.

For example, it is not uncommon for one of my patients to be “legally” blind in one eye from glaucoma and had mild disease in the other eye. For these patients, who might be on a medication unilaterally or have had surgery in one eye, the laterality is critical. Without knowing which eye received which treatment and has what outcome, this patient cannot be included in research. A prior surgery might have caused the uncontrolled glaucoma and led to the blind eye or treated the good eye when it could still be saved.

So for most (all?) ophthalmic data elements, I suspect that laterality is required.

Thank you very much @Christian_Reich, your clear response succinctly answers my question!

To discuss further:

If this approach (post-coordinated only) is the one selected for OMOP, would it make sense for this to perhaps be made even more explicit in OHDSI documentation: stating, for example, that the CDM models data using single-value time series events, and making clear what can and can’t be done with it as a consequence?

I appreciate that this is already addressed. However, if I am to give the perspective of a relative newcomer, there seems some leeway (in the form of qualifiers or the fact_relationship table) that perhaps allows some confusion to slip in. Would giving a hard-and-fast rule on data shape (aka “no post-coordination at all”), and accepting that this puts some things outside the scope of OMOP CDM, perhaps promote clarity and drive solutions to these problems through other innovations?

(Apologies if this is just a repeat of old conversations, as I imagine it quite likely is!)

@Mark_Danese @nathanh36 @enb thank you very much for your responses regarding the issue of representing laterality. This had been my impression too, so it’s great to have confirmation from those more knowledgeable than myself!

The topic of laterality representation is actually something that is being addressed in the Eye Care and Vision Research workgroup (workgroup list; sign-up form). It came up as important part of a vocabulary gap analysis that is currently being done. I’m working on this currently, so happy to discuss with anyone - drop me a message! I’m sure group leaders such as @Kerry_Goetz would similarly be happy to provide more info.

@willhalfpenny,

There is no uniform approach for concept coordination in OMOP. Both, pre- and post-coordination, have been used.

There are several methods for implementation of post-coordination including:

  • Measurement and Observation tables attribute-value pairs
  • Procedure_Occurrence.modifier_concept_id or Observation.qualifier_concept_id (allows for one modifier);
  • fact_relationship (allows for multiple modifiers, but should not be used for this purpose);
  • and the new method implemented in CDM v6, OMOP CDM v6.0, using observation_event_id and obs_event_field_concept_id (allows for multiple modifiers).

Ontological consistency of pre-coordinated concepts integrated from external vocabularies like SNOMED varies. In the OMOP-generated vocabularies like Cancer Modifiers, it is consistent.

It sounds like laterality is a critical modifier for eye conditions.

Neither Condition_Occurrence nor Measurement have a field for modifiers. Using Observation table to store laterality for post-coordination with Condition or Measurement seems to be the only available post-coordination solution. As I mentioned, Fact_Relationship should not be used for this purpose.

Pre-coordination means that every eye condition or measurement should be pre-coordinated with laterality. I quickly checked SNOMED, and it looks like eye disorders are pre-coordinated with laterality (e.g. Acute iritis of left eye; Bilateral acute iritis). Since this method is used to define a lot of eye conditions, it seems like pre-coordination should also be used for missing concept. @Christian_Reich - what do you think?

1 Like

Well, strictly speaking it is not what is in the data, but what is needed for the analytics. And apparently you want to follow the eye separately, and both eyes can have a different progression. It’s fine.

Regarding the solution: what @rimma said. We should use pre-coordinated eye diseases. We can also manually add such pre-coordinated concepts if they don’t exist yet.

The other methods I would not recommend. Because none of the analytical methods routinely support them and you would have to always use manual SQL-based queries. You end up having the laterality in the data, but it is essentially not usable. Also, the performance of the FACT_RELATIONSHIP gymnastics is abysmal.

Suggest using OMOP version 5.4 rather than v6.0 as @rimma mentioned. v5.4 has the Observation fields @rimma mentioned and v5.4 will be supported by the suite of OHDSI analytic tools. For some technical reasons there are no plans for the OHDSI analytic tool suite to support OMOP v6.0.

V6.0 is a dud. We will go to 6.1. Not soon, though.

Just have the stuff you want to study pre-coordinated, rather than the various gymnastics with the data model.

Thank you all for your responses!

On the topic of laterality, it seems clear that pre-coordination should be the approach. Fortunately, my understanding is that this is the path the Eye Care and Vision group are currently going down. Affirmation that this is the correct approach is helpful, and I will be certain to communicate to the group the feedback above. As @rimma mentions, many concepts are pre-coordinated already, so it will just be a case of identifying and adjusting the subset that aren’t.

Regarding the more general question of data shape within the CDM: I think I will avoid overloading the forum and stealing time with further theoretical musings! I will note, though, that I think the implications, from an information theory perspective, are both interesting and pragmatically relevant. I’d certainly be happy to discuss further with anyone that feels similarly!

1 Like

That would be the CDM Working Group. @clairblacketer is in charge. Bring it on. :slight_smile:

t