Weather conditions and assessment of pain

I’m currently involved in an arthritis project that collects self-reported data on joint pain. One of our survey questions asks participants to specify when they experience pain and the corresponding weather conditions at that moment (e.g., sunny day, snow, rainy day, etc). While reviewing the CKMs, I couldn’t locate an archetype that addresses this specific scenario. I’m curious if there has been any prior consideration or development of a case that involves gathering such information, perhaps within an incubator that is not publicly accessible at the moment.

1 Like

This is very interesting! My first thought is that this would be a kind of State information. It’s a parameter which changes with time, and is something you observe and not part of the setup of the observation procedure, so it doesn’t belong in Protocol. Neither OBSERVATION.story nor OBSERVATION.symptom_sign_screening has a State group as of now. Maybe we should add one, possibly with just a SLOT for adding a CLUSTER about environmental conditions?

Hi Vanessa,

Environmental conditions might be useful to evolve. Created a few moments ago, in 2008 :grimacing:, and intended to be nested within the State for the Body temperature archetype.

1 Like

Thanks @siljelb and @heather.leslie for the quick reply.
I see my mistake was not searching for the correct keywords, I searched for meteo, meteorology, weather… But indeed it does not completely fit my use case, maybe as suggested a new data element with some name “type of environment event” would be nice to evolve it. For example in my case it asks “What is the weather like? Rain / Snow / Cloudy / Hot / Cold / Temperate” but i think theres semantics mixed, rain, snow and cloudy would be the event type but hot, cold and temperate I understand it more as a personal sensation about the event but of course there might be even other interpretations. I will have more time next monday to think more about this.

1 Like

I think the “Environmental conditions” archetype can be improved by looking at the kind of output you get from a weather service API. This is an example from my home automation system, and I think the “condition” element to a certain degree matches what you’re thinking of?

1 Like

I agree that this could be messy unless we carefully tease out the use case and understand the semantics, to ensure it may be suitable for re-use.
Is it necessary to include inside ENTRY archetypes? Or could/should it be a standalone questionnaire about the subjective conditions?

The notion of joint pain being worse in certain weather conditions is not simple - assertions of cold or warm or hot can be very contextual. Eg cold in terms of absolute temperature or that I’m always cold because I can’t afford to have heating in my house or I can afford heating and I never go out in the snow so it doesn’t matter.

1 Like

I agree that these ‘what is the weather like’ questions feel very subjective, especially as actual weather stats are so readily available . Perhaps we could add something to environmental conditions, to capture the patient’s subjective perception alongside the kind of objective weather data that Silje highlighted? Or indeed just capture alongside as questionaire?

I do wonder if the the formal environmental data should sit as a separate entry since it is not really a patient state per-se, and might apply to multiple observation or other assessments.

Having said that, it is not really a patient Observation at all, either, though that would probably be the best fit from a tech perspective - times, averages etc.

I’ll not be of any help with the modelling; just chiming in to say that I’ve heard people claim they can forecast the weather, i.e. they experience pain a day or two before it rains, and not anymore when the raining is actually taking place. You might want to take that into account as well. :slight_smile:

1 Like

Are you suggesting we need a new ‘Crystal ball gazing’ archetype? :rofl:


Hi! that’s smart! Yes, condition could be a possible naming option.

Sadly i don’t have much more use cases to think about but I see your point. Maybe staying as cluster that could be added to other entry archetypes until we have more cases to think about - I might have some more during this year, mostly from patient reported data and i can add to this topic as i receive them.

Now that you mentioned that, its very common in Portugal to hear from the elderly “My knee is hurting, it will rain tomorrow”, and in fact it rains :joy:


So with the right archetypes, maybe one day we can do some analysis of our rheumatoid arthritis patient’s predictions and the actual weather?

Historical weather data is available for almost any place in the world. Why put this data into CDR? Analysis can be done today by matching patient data in the CDR with weather data.

Do we really want to ask practitioners to also enter weather data? I heard they don’t enjoy entering the data.

Where it is clinically relevant, it is appropriate to store ambient temp and maybe humidity eg an exposure situation or even a forensic situation of comparing body temperature vs ambient temperature to determine the time of death. Outlier situations, for sure but still a real-world use case.

Others may have other use cases that are more mainstream.

No one is saying practitioners or patients need to enter the environmental temp - the source can be automated from external sources, if available.

1 Like