# Weather conditions and assessment of pain **Category:** [Ask IEB](https://discourse.openehr.org/c/ask-ieb/37) **Created:** 2024-02-02 15:41 UTC **Views:** 630 **Replies:** 31 **URL:** https://discourse.openehr.org/t/weather-conditions-and-assessment-of-pain/4900 --- ## Post #1 by @vanessap Hello! 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. --- ## Post #2 by @siljelb 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? --- ## Post #3 by @heather.leslie Hi Vanessa, [Environmental conditions](https://ckm.openehr.org/ckm/archetypes/1013.1.165) 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. --- ## Post #4 by @vanessap Hi! 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. --- ## Post #5 by @siljelb 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? ![Screenshot_20240203_180321_Home Assistant|291x499](upload://oQEv6f3e448FJgje1BcN0iNl6Sh.jpeg) --- ## Post #6 by @heather.leslie [quote="vanessap, post:4, topic:4900"] 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. [/quote] 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. --- ## Post #7 by @ian.mcnicoll 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. --- ## Post #8 by @matijap 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: --- ## Post #9 by @heather.leslie Are you suggesting we need a new 'Crystal ball gazing' archetype? :rofl: --- ## Post #10 by @vanessap [quote="siljelb, post:5, topic:4900, full:true"] 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? ![Screenshot_20240203_180321_Home Assistant|291x499](upload://oQEv6f3e448FJgje1BcN0iNl6Sh.jpeg) [/quote] Hi! that's smart! Yes, condition could be a possible naming option. [quote="heather.leslie, post:6, topic:4900, full:true"] [quote="vanessap, post:4, topic:4900"] 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. [/quote] 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. [/quote] 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. [quote="matijap, post:8, topic:4900, full:true"] 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: [/quote] 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: --- ## Post #11 by @heather.leslie So with the right archetypes, maybe one day we can do some analysis of our rheumatoid arthritis patient's predictions and the actual weather? --- ## Post #12 by @borut.jures 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. --- ## Post #13 by @heather.leslie 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. --- ## Post #14 by @vanessap 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 https://openweathermap.org/weather-conditions What do you all think? --- ## Post #15 by @heather.leslie 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 Heather --- ## Post #16 by @SevKohler 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 ... https://www.gesundheitsforschung-bmbf.de/de/calm-qe-medizininformatik-use-case-copd-und-asthma-longitudinale-und-sektorubergreifende-16644.php @vanessap i think there is some clear overlap here. But in our case its more quantitative values, as in the environment archetypes. --- ## Post #17 by @ian.mcnicoll Agree - is it a huge misuse of 'symptom/ symptom questionnaire' to capture 'perceived environment' - 'Feels windy, feels hot , feels cold'? --- ## Post #18 by @siljelb [quote="ian.mcnicoll, post:17, topic:4900"] is it a huge misuse of ‘symptom/ symptom questionnaire’ to capture ‘perceived environment’ - ‘Feels windy, feels hot , feels cold’? [/quote] Yes :joy: [quote="ian.mcnicoll, post:17, topic:4900"] questionnaire’ to capture ‘perceived environment’ - ‘Feels windy, feels hot , feels cold’? [/quote] What about Exposure screening questionnaire? Maybe a long shot, but to my mind closer than symptom. --- ## Post #19 by @ian.mcnicoll [quote="siljelb, post:18, topic:4900"] Yes :joy: [/quote] Harsh .. :cry: Probably fair --- ## Post #20 by @vanessap 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. --- ## Post #21 by @heather.leslie Thanks Vanessa. Tricky. From my POV, I'd prefer to protect this archetype as a factual collection of actual environmental conditions but suggest that we think about developing a 'softer' CLUSTER archetype to carry patient perceptions re their environment, including a 'category, type or status' with a value set such as you suggest, and an accompanying optional narrative description for more detail. It could be nested within the Environmental conditions CLUSTER if both need to be recorded simultaneously. Are there other data fields that you have identified? Or should it be an OBSERVATION of a broader range of patient perceptions that would provide context to other data stored in the same COMPOSITION? No specific use case in mind, just thinking laterally and out loud here. Cheers Heather --- ## Post #22 by @thomas.beale [quote="siljelb, post:2, topic:4900"] My first thought is that this would be a kind of State information [/quote] Technically, 'state' in Observation means 'state of the patient (as a whole)' e.g.: * consumed 75g glucose 2h ago * not conscious * just ran 10k and so on. The weather is really an environmental condition which might influence a person's symptoms, or even cause them. Environmental conditions like extreme heat or cold obviously relate closely to difficulty breathing, hypothermia etc, but we tend to treat ambient temperature as something like patient state, rather than separating out environmental conditions. In an ideal model, there is probably a good argument for adding a /environmental branch of Observation (alongside /data, /state and /protocol) to properly capture environment conditions, but that's a change to the RM (which is perfectly possible, since it's an addition, it won't break anything). Avoiding breaking the RM could be solved by adding in a generic Environmental condition slot under Observation.state. Which is pretty much your conclusion ;) --- ## Post #23 by @thomas.beale [quote="borut.jures, post:12, topic:4900"] 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. [/quote] Technically true, but environment data would only be added if the clinician thought it relevant to the patient note. Mostly it wouldn't be. But a lack of heating or air-conditioning in the homes of less well off people is a very common 'social determinant of health' (SDOH). I think the case under discussion here though really is more like subjective patient story kind of stuff, not objective observation by the clinician. I'd suggest environmental conditions more generally are often of interest to record e.g.: * temp * high winds * very low humidity * extreme pollen * extreme noise * smoke * air pollution * sources of stress, e.g. warzone activity --- ## Post #24 by @heather.leslie [quote="siljelb, post:2, topic:4900"] My first thought is that this would be a kind of State information [/quote] Of course, we have a long-standing example of this in the Body temperature archetype - a SLOT in State to capture the ambient temperature/wet bulb etc at the time when the body temperature was measured, eg in extreme climate exposure situations or immediately after death to assist in establishing the time of death. This was the original use case for the CLUSTER.environmental_conditions and assumed it could be reused within the context of other ENTRY archetypes. But maybe it is worth revisiting... --- ## Post #25 by @Maximilian_Meixner Hello everybody, I work on the CALM-QE project that Severin posted above. Among other things, we record environmental conditions in the patients homes with a mobile weather station. I was also thinking to use the Cluster archetype "environmental conditions" for temperature, pressure and humidty. But I don't know where to include this cluster. If I got it correctly then the original intention was to include environmental conditions into the "body temperature" observation archetype (under State). However since we're not recording a patients body temperature but only the ambient temperature in their homes, I was thinking to include it in the "Temperature" observation archetype (openEHR-EHR-OBSERVATION.temperature.v0). Unfortunately for the latter, there is no State information with the respective cluster slot available. Is there an option to include a slot for environmental conditions in the "Temperature" archetype as well? Or does anybody have a suggestion for an appropriate slot in other archetypes? Thanks in advance. --- ## Post #26 by @heather.leslie Hi Maximilian, The Temperature OBSERVATION is intended to record a measurement of temperature of a specified object, for example the temperature of an donor organ prior to transplantation. It is probably not quite right for your use case. The CLUSTER was originally intended to provide context about the state of the patient at the time of body temperature measurement, to enable appropriate interpretation of the measurement. However, given the other comments in this thread, perhaps we do need to think how best to create a standalone, purpose specific archetype for Environmental conditions that is potentially broader in scope than the current CLUSTER. - Option 1: To transform the CLUSTER.environmental_conditions into OBSERVATION.environmental_conditions. This would effectively abandon the CLUSTER and only use an OBSERVATION external to the other measurement archetypes. This means we LOSE the ability to record the environmental conditions directly in the State, and lose the direct comparison between body and environmental temp which is critical in extreme heat or cold exposure situations. - Option 2: Create an empty OBSERVATION.environmental_conditions containing only a SLOT in which to nest the CLUSTER.environmental_conditions to support reuse both in this new OBS and also other Vital signs archetypes, as per the original intent. This second option is an ugly modelling solution, but we also want to ensure that we don't duplicate data elements in more than one archetype. Any more inspired possible solutions from other modellers? --- ## Post #27 by @ian.mcnicoll Id agree withese 2 options but would go for option 2. We have something similar with ambient oxygen which is needed in the context of some soecific archetypes like pulse oximetry or lab gases but in news tyoe assessments is often recorded outside any individual specifc observation. --- ## Post #28 by @heather.leslie I suspect some analysis of use cases might give a clearer answer - possibly a hybrid solution. I'm thinking along the lines of: - Create an OBSERVATION containing only data elements used to record the true 'weather station' context such as the atmospheric pressure, pollution/pollen measurements, whether it is physically raining outside the window. - Keep the CLUSTER as is, and nest it within the OBSERVATION above and the other clinical measurement OBSERVATIONs as before, to prevent duplication and promote reuse. --- ## Post #30 by @linforest Maybe irrelevant for this topic: For personal running (and some other physical activities), the ambient temperature and relative humidity have obviously affected my running performance today, including pace decreased and heart rate increased. --- ## Post #31 by @ian.mcnicoll See https://discourse.openehr.org/t/weather-conditions-and-assessment-of-pain/4900 --- ## Post #32 by @Colin_Sutton Hi Vanessa, If you are using a phone to collect the data, the app can record the environmental conditions at the time and place, without recording the place of the phone. --- ## Post #33 by @vanessap Found this the other day: https://www.arthritis.org/weather It gives a prediction of arthritis and pain depending on the weather in US --- **Canonical:** https://discourse.openehr.org/t/weather-conditions-and-assessment-of-pain/4900 **Original content:** https://discourse.openehr.org/t/weather-conditions-and-assessment-of-pain/4900