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.


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.


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?


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.


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.

1 Like

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:


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

Hi! I can finally come back to this topic. I had some discussions with the project members I am working with and we thought about 2 new data points for the environmental conditions archetype:

  • condition type, as @siljelb mentioned, to record sun/clear sky, clouds, snow, rain, mist, thunderstorms, windy - coded or free text
  • perception/sensation to environmental temperature (by individual/participant) - cold, warm, humid, etc - coded or free text

I was looking to this for reference Weather Conditions - OpenWeatherMap
What do you all think?

1 Like

Hi Vanessa,

I’d be quite excited to see an app simultaneously recording relevant weather-related variables, eg imported from a local weather station while recording a symptom- or pain-rating assessment.

However, I’m not clear on how recording subjective values about weather observations by the patient helps to understand the impact of weather on a symptom or diagnosis. This is compounded if interpersonal reliability about the proposed values may vary - eg discerning between ‘few clouds’ from ‘scattered clouds’.

I know many people anecdotally associate cold or hot weather, high or low humidity etc with an improvement or worsening of their symptoms, but is it the same for the observation of ‘scattered clouds’, ‘clear sky’ or ‘haze’?

I would love to see us recording the impact of weather conditions/climate change on health better, but I think we need to record the measured observations at the time of recording symptoms - more along the lines of relative and absolute temp/humidity, air quality/smoke/particles, wind speed and pollen count on high allergy risk days, etc. Maybe I’m wrong, but I also suspect similar combinations of these measurementsmay result in variations in the observable weather manifestations depending on other factors such as altitude.

Please let me know more about your use case. Maybe I’ve missed the point.

Kind regards



We have a project running (modeling started) to combine weather station data from the ministry + a local weather station that the patients will have in their home. These will be used to correlate with asthmatic disorder and COPD …

@vanessap i think there is some clear overlap here.
But in our case its more quantitative values, as in the environment archetypes.

Agree - is it a huge misuse of ‘symptom/ symptom questionnaire’ to capture ‘perceived environment’ - ‘Feels windy, feels hot , feels cold’?


Yes :joy:

What about Exposure screening questionnaire? Maybe a long shot, but to my mind closer than symptom.

1 Like

Harsh …


Probably fair

1 Like

Hi Heather! I completely agree that we should instead get the objective data for the weather and not the patient’s subjective perception but the issue relies on what we can access to monitor where the patient has been over the last week from his phone - for that we need to record the GPS coordinates to call the different weather APIs or even the one that is the most accurate from where the participant is passing at the moment of recording the joint pain symptom. Since we have a special kind of participants - they can pass 4 different countries in 1 day, we are forbidden by who’s giving the funding to take any information about the position of participant. If we didn’t have this condition, we would have taken the most appropriate approach. The researchers still believe they can do an approximation with this patient’s perception.