How do we handle instances where certain fields or information in the source data cannot be mapped to corresponding fields in the OMOP tables?
Can you provide examples of what fields you have in your source that you
think don’t map, and how you use that information to support your analytic
use cases?
Hello Patrick,
Examples of source data fields could be things like carer details, nursing assessments and certain patient demographic information such as residency and employment status. At this stage, I am unable to tell you how this information could be used to support our analytic use cases, as our aim is to port all information found in the source data over to OMOP before applying different use cases for research purposes.
Totally understood. We call that approach the “attic” approach: Keep all data just in case you might need it in future. That’'s what people do with the stuff in their attic, and, as we all know, nobody ever goes to the attic to pull anything out of there. It all gets disposed of when you move house. 
The reason the OMOP CDM is succesfull is it’s focus on the use cases, making it slim and efficient. It supports use cases that people really have. For everything else - why would you bother creating a CDM?
Your concrete use cases:
- Carer details go into the PROVIDER table. Or is there anything missing?
- Nursing assessments can go into the OBSERVATION table. What kind of assessments do you have in mind?
- Residency: What do you mean? There is a location_id field for the address. Or what do you mean by residency?
- Employment: Not sure how this is data relevant to the clinical data of a patient. But you could store it in the OBSERVATION table.
Let us know.
1 Like
Hello Christian,
Thanks for providing a label to our approach…good one!
- The PROVIDER is a good choice. We would need to store information about a carer’s availability post-discharge. Could we still use this table?
- We too thought of using the OBSERVATION table to store information sourced from nursing assessments. The assessments would be discharge screening, respiratory infection screening and waterlow scores to name a few. There are also nursing care plans to be factored in too.
- I should have been more clear about what I meant by residency. Its whether the patient is a permanent or temporary resident of the country.
- I agree about the relevance of employment to the clinical data for the patient. However it is present in the source data and our attic approach needs to consider all data items available.
1 Like
The label was supposed to discourage you, not encourage you to continue with it. But since you are doing exactly that: 
You can always add fields in your private implementation. But no standard tool will ever use it. If you want that, you will have to get the additions through the CDM Working Group. They are running a tally of change requests.
There are Concepts like
4309401 Respiratory assessment
4259232 Respiratory care assessment
40482931 Assessment using Waterlow pressure ulcer risk scale
Discharge - is that urinary discharge, or discharge from a hospitalization?
No idea what that means.
Sounds like a local private addition of a field like residency_status in the PERSON table.
Same thing. employment_status.
But I will try it one more time, Vimala: If I were you I’d prepare for these, but wouldn’t put them in until there is a use case. Otherwise you have a ton of stress with them, and nobody ever reads those fields. Have seen it time and time again.
1 Like
Hello Christian,
I have a follow up question in regards to mapping nursing assessment questions to concepts in OMOP. Are we expected to map source data to a particular domain in a specific vocabulary? For instance, the concepts you suggested in your previous reply, all originate from SNOMED. So should all questions for a respiratory assessment be mapped to SNOMED concepts solely?
I have just started mapping a nursing assessment and have found that I can map to concepts from a couple of different vocabularies. So I would like to know what the best practice is for mapping?
Regards,
Vimala
You don’t have to use SNOMED, but since it has so many concepts from the clinical reality it is often a good choice. For your assessments or questionnaires, also look to LOINC. They have a lot of this stuff.
And yes, Concepts have to be in the right Domain. So, if you are mapping a drug it should be mapped to a Concept from the Drug Domain, even though e.g. sometimes tests for measuring the level of a drug in the blood sound like the Drug itself by the description. Hierarchy is also important. Check out the Dads and Moms of the Concept you want to map to, in order to make sure it’s in the right family.
Hello Christian,
Thanks for your reply. However I am still unclear on the approach to take when different questions in a clinical assessment can be mapped to different vocabularies. For instance, I am working on a blood transfusion checklist and a couple of questions can only be mapped to SNOMED and others to LOINC in the very same assessment. So the mapped data would end up being a mixed bag of concepts. Is this an acceptable practice?
Regards,
Vimala
In principle yes. Can you show a little bit?
Hello Melanie,
could the post stay a little longer? This discussion would be helpful to me and my colleagues.
Thanks!
Hello @Agota_Meszaros,
I accidentally posted my response to this topic here. I deleted this post because it is a duplicate and in the wrong location!