# Physical activity archetypes; exercise, steps etc from apps & devices **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2020-09-15 10:23 UTC **Views:** 1282 **Replies:** 11 **URL:** https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983 --- ## Post #1 by @erik.sundvall Work has been done to create physical activity archetypes representing physical exercise, steps etc from (personal) health apps & devices in a vendor neutral openEHR based format. Backround and models can be found in the readme file at the GitHub project https://github.com/regionostergotland/Physical_activity That also contains subdirectories with mindmaps and archetype proposals ### Mindmaps The directory [/mindmaps](https://github.com/regionostergotland/Physical_activity/tree/master/mindmaps) contains mindmaps used for requirements gathering etc. You may need to download Xmind to view/explore/edit them https://www.xmind.net/ Note that the link-symbols in the mindmaps that lead to sources, API descriptions etc. Directory content: * `platforms.xmind` exploration of data (mostly physical activity) gathered by different personal health platforms (Google Fitness, Apple Health, Samsung Health, Withings, Garmin, Polar, Strava, MyFitnessPal etc.) * `sleep.xmind` Data about sleep in various platforms * `activities.xmind` Aggregation/mashup of activity datapoints from different health platforms. Useful as background for modeling. * `PhysicalActivityInvestigation.xmind` some previous example gathering and modeling thoughts, now in part superseeded by recent archetype modeling ### Archetype proposals Directory containing experimental archetypes created for the purpose of modeling self recorded physical activity. Different modeling approaches are explored (as will be described in [next post in this topic](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/2)). Each batch of archetypes is stored in its own subdirectory with documentation (readme-file) and example templates. * Specialization-focused modeling in [/proposals/2019-07-03_sbrs](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-03_sbrs) * Cluster-focused modeling in [/proposals/2019-07-12_clst](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst) ### Accessing archetypes & templates Archetypes and templates can be cloned or downloaded from the repository and manually loaded in to any openEHR-compliant designer application. They can also be browsed from the web based Archetype Designer at https://tools.openehr.org/designer/#/ by instructing it to use the repositoryhttps://github.com/regionostergotland/Physical_activity ### Now what? During a archetype modeling skype meeting with Australian, Norwegian and Swedish modelers today it was decided to try to pick up the international discussions regarding this again. This time using this openEHR discourse forum. (Some starting questions will follow in next post from me.) --- ## Post #2 by @erik.sundvall Below follows a description of modeling alternatives and some questions to discuss, originally posted by Noah Hellman as [a Github issue](https://github.com/regionostergotland/Physical_activity/issues/1) ## Overview of the issue The primary issue with modelling physical activity is that there is a lot of activities. Some of these activities are similar to each other while some are not. There will therefore unavoidably be overlapping elements between different activities. For example, cycling and running can share a lot of elements. When recording a cycling session, relevant data include distance, duration, speed, heart rate, incline/elevation change and energy expenditure. All of these metrics may also be relevant for a running session. There are however also elements that may only be relevant for either cycling or running. Things like power output, pedaling rate and bicycle type is only applicable to cycling, while things like stride length and footwear is only applicable to running. The problem is therefore, how do we model all possible activities without having to model elements that are shared between different activities multiple times? ## Types of sharing Before we jump into solutions, we can group shared elements into the below three categories. ### Common for all Common elements are those that can be relevant for any type of physical activity. Examples may be heart rate, energy expenditure, PAL and MET. ### Vertically shared / inherited Vertically shared elements are elements that are inherited to all "below" activities if you arrange them in a hierarchy. Let's say we structure activities like this: ``` Physical activity ├── Distance activity │ ├── Cycling │ ├── Running │ │ ├── Long distance running │ │ ├── Middle distance running │ │ └── Sprinting │ └── Swimming └── Stationary activity ├── Aerobics └── Strength training ├── Bodyweight training └── Free weight training ``` All activities under the distance branch will inherit elements like distance and speed. Further, all activities under the running branch will inherit elements like stride length and other running dynamics. Elements that are common for all activities can also be considered inherited elements as all activities inherit them from the root activity. ### Horizontally shared It may however be difficult, if not impossible, to arrange activities in a hierarchy where all shared elements are inherited vertically. There may therefore be elements that are instead shared horizontally. In the above example, data about elevation gain may be of interest to both walking/running and cycling activities but not for swimming. All three do not inherit these elements from "Distance activities" as they are not relevant for all distance activities. Instead, walking/running and cycling share these elements horizontally. In this example it is possible to add another layer to the hierarchy like this; ``` Distance activity ├── Varying elevation activity │ ├── Cycling │ └── Running └── Static elevation activity └── Swimming ``` in order to make elements for elevation change inherited. But adjusting the hierarchy to make all elements inherited may make for a very messy hierarchy and may even be impossible if two distant activities happen to share elements. ## Possible solutions Below are some possible solutions that have been discussed at the moment. Each solution has a list of pros and cons that are labeled either "usage" or "modelling". "Usage" means that the pro or con applies to the usage of the archetypes after they have been reviewed and published. "Modelling" means that it applies to the modelling and review process before publishing, including republishing. ### Single large archetype One option is to use a single large archetype for all types of physical activity. In this case, all elements for all possible activities will be included in this archetype. Pros: * (modelling) Simplest approach to modelling. * (usage) Easy to find which archetype to use. Cons: * (modelling) It's hard to account for all possible activities at first and it may require frequent updating. * (modelling) May become very large and cumbersome to maintain. * (usage) Cumbersome to use if large and including many elements that are not relevant for the activity you wish to record. * (usage) Sessions with multiple activities (e.g. a triathlon) must be divided into separate observations. ### Specializations Specializations of a main "Physical activity" observation can be used to handle vertically shared elements. By arranging activities in a hierarchy and creating a observation that specializes its parent for each node, all elements can be accounted for if all elements are vertically shared. When creating a new activity, only new elements will have to be modeled. Pros: * (usage) Simple to use, simply find the archetype named most similarly to the activity that you wish to record. It will only include elements that are related to that activity. Cons: * (modelling) Requires careful planning when arranging the activities in order to not having to make huge arrangement changes later if more activities appear and new patterns emerge. * (modelling) Many archetypes to review if multi-level specialization is used. * (modelling) Cannot be reused for non-observation archetypes. May require similar elements to be modeled multiple times. * (usage) Sessions with multiple activities must be separated into multiple observations (one for each activity). Single-level specialization has been experimented with in the [sbrs archetypes][1]. ### Clusters and cluster slots Clusters along with cluster slots can be used to account for horizontally shared elements. One can use a "Physical activity" observation with general elements and cluster slots for specific elements. It's possible to use clusters for a whole activity or clusters for a specific set of elements that are shared between multiple activities. Pros: * (usage) Sessions with multiple activities can be placed in a single observation. * (modelling) Can be reused for non-observation archetypes, e.g. instructions. Cons: * (modelling) May be a lot of cluster archetypes to review. * (usage) May be cumbersome and/or confusing to set up all clusters when creating templates. Clusters have been experimented with in the [clst archetypes][2]. ### Separate observations Separate observations can be used for all types of shared elements. By separate observation we refer to creating an observation that is not a specialization of "Physical activity" and using the new observation next to it. For example, there exists a "Pulse/Heart beat" observation already that must be placed next to the "Physical activity" observation if used in order to record heart rate. Pros: * (usage) Can be reused on their own for other observation purposes. Cons: * (usage) Splits a single session into multiple observations. Observations for the same session are linked with each other only by time. They are also by linked by their common composition, but there may be multiple sessions in a single composition. * (modelling) May be a many archetypes to review if used extensively. ### Combinations of the above As all of the above approaches have both pros and cons, it might be possible to find a sweet spot by combining them and creating a decent balance. Both the sbrs and clst archetypes have attempted to combine them in different ways. The sbrs archetypes primarily use specialization but also has clusters to account for horizontal sharing. The clst archetypes has a single main observation with cluster slots, but the clusters for these slots are themselves specialized. [1]: https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-03_sbrs "sbrs archetypes" [2]: https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst "clst archetypes" ## Further discussion Further discussion may be required to find a good solution. Some questions that I can think of are: * Do you agree with the pros and cons listed above? * Are there other pros and cons to the solutions? * Are there other types of solutions that could be used? * Can you think of more ways to combine the different solutions? * Are there small or big alterations that can be made to the existing proposals? --- ## Post #3 by @linforest Such an amazing effort deserves more attention and participation from the community. --- ## Post #4 by @vanessap Thanks for the push! I wasn't aware of this initiative either. I will bookmark it as I will need this content soon. --- ## Post #5 by @linforest Such a situation for SMEs, adopters and developers calls for a more in-time and agile mechanism to facilate the curation/accumulation/update of domain knowledge (not limited to traditional healthcare/medicine, but including SDOH related knowledge). In my personal experience, this may be one of the pain points that is hindering the wider adoption of openEHR. --- ## Post #6 by @heather.leslie @erik.sundvall This is a great summary of all the options and issues. I'm not sure how this escaped my radar. I spent some considerable time trying to investigate the modelling patterns around exercise and there is huge variability for each activity - add reps and intensity/effort and rest times; single activities like a sprint vs HIIT repeats etc. Documentation is patchy and the patterns seem to have been done differently in each app or wearable reps and effort and rest times. In order to solve this question about the OBSERVATION recording physical activity, in theory we also need to understand the broader domain so that we can identify and optimise reuse, or understand that it is not useful. [2019 11 21 Physical activity.xmind|attachment](upload://gyGE5skBV4luxdzTHd8TpxmL8e6.xmind) (347.8 KB) Attached is the mindmap I worked up in 2019, which includes models you shared from Linkoping and a section with a proposed pattern for archetypes and data elements. It's a first draft that has not been reviewed nor revised in the face of current modelling patterns, but may be useful. Excuse my crappy documentation but without spending more time, I'm not even sure which tab is the most recent - either the date or 'Proposed'. Looks very similar at first glance. I think the main frustration for me at the time was a lack of documentation about current implementations that will better inform a coherent data pattern being developed. Does anyone know if the situation is any better now? Are there any standards or published specs? --- ## Post #7 by @linforest Modelling patterns/best practives would be desriable/valuable, esp. for emerging domain concepts like SDOH-related concepts (such as physical activity). Is there any sources for such patterns/best practives? --- ## Post #8 by @linforest [quote="erik.sundvall, post:2, topic:983"] Clusters have been experimented with in the [clst archetypes](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst). [/quote] Hi, @ [Erik](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/2). Why not model *Pace* as an element of type [ DV_QUANTITY](https://specifications.openehr.org/releases/RM/Release-1.1.0/data_types.html#_dv_quantity_class)? Is this because the pace (e.g., 5:30/km) shouldn't be represented as **330 s/km** but **5:30/km** (most runners are likely fond of this expression) or **P5M30S/km**? The expresion "s/km" is a valid UCUM unit. **Note about the element *Pace* in the README for [proposals\2019-07-12_clst](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst) (Cluster-focused modeling):** ``` The details subcluster also contains another cluster; pace. Primarily when running, speed is almost exclusively measured in terms of minutes per km or minutes per mile, also known as pace. It is however not possible to use min/km as unit for an element as it is a duration divided by a distance. An element may either be a duration or a quantity, not a mix of the two. A cluster containing both the duration and the distance has therefore been used. A 5:30 /km pace can then be modeled by setting the "Time per distance" element to 5:30 and the distance element to 1 km. ``` **Definition of the element *Pace* in the Archetype *[openEHR-EHR-CLUSTER.distance_activity-walking_running.v0.adl](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst/openEHR-EHR-CLUSTER.distance_activity-walking_running.v0.adl)*:** ``` CLUSTER[at0015] occurrences matches {0..1} matches { -- Pace items cardinality matches {1..*; unordered} matches { ELEMENT[at0016] occurrences matches {0..1} matches { -- Time per distance value matches { DV_DURATION matches {*} } } ELEMENT[at0017] occurrences matches {0..1} matches { -- Distance value matches { C_DV_QUANTITY < property = <[openehr::122]> list = < ["1"] = < units = <"km"> > ["2"] = < units = <"[mi_i]"> > ["3"] = < units = <"m"> > ["4"] = < units = <"[yd_i]"> > ["5"] = < units = <"[ft_i]"> > > assumed_value = < units = <"km"> magnitude = <1.0> precision = <-1> > > } } } } ``` --- ## Post #9 by @erik.sundvall Hi! I don't remenber all the details, but would guess that 1. many systems by default are pretty bad at displaying minutes/km or minutes/mile and I don't think the archetype editors supported it as a selectable unit back then (haven't checked now) 2. the distance chunk is usually fixed for a patient/country (miles in some not so SI-standard loving contires, and km in the rest of the world) so that can easily be locked down in a template and just the minutes+seconds recorded and shown by an app/user. Great to see renewed interest in this topic! Credit for the detailed work/description goes primarily to an ex-student and summer intern at Region Östergötland, the somewhat anonymous/privacy-prefering Noah https://github.com/hellux and his fellow students in a preceeding student project. --- ## Post #10 by @linforest @erik.sundvall, thank you so much for your help. It's a really valuable openEHR modelling effort. Recently I'm trying to learn template design with these resources. --- ## Post #11 by @siljelb The units file https://github.com/openEHR/specifications-TERM/blob/master/computable%2FXML%2FPropertyUnitData.xml does have the property "pace", with units min/km, min/mile, and s/m. openEHR doesn't currently have a datatype which supports an ISO8601 duration per length unit (for example PT4M30S/km), so if you run a km in 4m30s, it'd have to be represented as 4,5 min/km. If we need to represent it using a proper duration, we'd currently need to split it into two elements; a DV_DURATION for the duration and a DV_TEXT for the length unit. --- ## Post #12 by @linforest Thanks, @siljelb --- **Canonical:** https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983 **Original content:** https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983