Add OBSERVATION table fields

[jbnuh]

Is there an existing issue for this?

• [X] I have searched the existing issues

Is your proposal related to a problem or functionality gap?

The SDE programme has defined a minimum OMOP data model for Cohort Discovery. Observation-related data is included as it is relevant to research in the domain. It would be great if the following fields were included in the capability of CaRROT-Mapper.

Describe your proposal

Please could you add the following fields from the OBSERVATION table?

value_as_number value_as_concept_id

Describe alternatives you've considered

No response

I'm part of a Project Team

No response

Anything else?

No response

Are you willing to contribute to developing this feature?

🎨 Yes, I'm keen to be involved in design discussions.

[AndyRae]

Related to #711

Initial impression is that: value_as_number is a further rule added, similar to the current measurement process.

But value_as_concept_id will be complex, and we should confirm that this is a requirement, as the UI for Rquest would need to support it.

[erummas]

Hi @AndyRae , just curious to know when these features will be added. I was hoping to get the value_as_number feature added quicker as that is just replication of field already functional in the measurement table. Due to the nature of data in questionnaires most fields have scaler values and thus need to be mapped to this field which unfortunately is currently unavailable in Observation domain.

[AndyRae]

Hi @erummas - as in our roadmap we're lining these up for July - September.

This code is a place of uncertainty for us, so I'd appreciate @spco thoughts on the proposed fix.

If value_as_number is as small as it initially looks, then having this released this month would be realistic.

[erummas]

Hi @spco could you please share your thoughts on the implementation of value_as_number field in observation. It is extremely crucial for the questionnaire based data.

[spco]

I agree that value_as_number should be simple, and treated in the same way as in the measurement case.

As for value_as_concept_id, that seems it would require Carrot-Mapper UI changes, and I'm not sure whether it would also require Carrot-CDM changes - I would guess so.

The point above about whether it's a requirement for RQuest-based flows is also relevant, but only in terms of prioritisation.

Suggest we proceed with the quick implementation of value_as_number, and either leave this open for value_as_concept_id, or create a separate issue for that given the quite different nature.

[erummas]

@spco could create a separate issue as implementing it will be very different from value_as_number. Sorry to bother but could a rough time estimate be given for the implementation of value_as_number?

[AndyRae]

@erummas we're putting all our effort into fixing #761 this week, as it's an urgent fix for us. But if we manage to get a fix this week, we could prioritise value_as_number.

One thing that would help our team, is having a test case we can verify. Just a simple example of applying it as a mapping, so we can ensure it's generated correctly in the rules. If we have that, I think realistically we could have this deployed late next week.

[erummas]

@AndyRae that's understandable. Thanks again to you all for working so quickly through the issues.

[erummas]

@AndyRae you can use this scan report to test. The concepts for the two columns in table dataset_obs.csv are 4208903 - Age at event 4037632 - Number of exposures ScanReport.xlsx