# Physical activity archetypes; exercise, steps etc from apps & devices
**URL:** https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983
**Category:** Clinical
**Tags:** archetype, physical-activity
**Created:** [15 September 2020 10:23 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983 "2020-09-15T10:23:57Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [15 September 2020 10:23 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/1 "2020-09-15T10:23:57Z")
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](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/](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/#/](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.)
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [15 September 2020 10:44 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/2 "2020-09-15T10:44:27Z")
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:
```auto
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;
```auto
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](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-03_sbrs "sbrs archetypes").
### 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](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst "clst archetypes").
### 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.
## 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?
---
### Author:  [@linforest](https://discourse.openehr.org/u/linforest)
#### Post date: [12 August 2024 07:43 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/3 "2024-08-12T07:43:07Z")
Such an amazing effort deserves more attention and participation from the community.
---
### Author:  [@vanessap](https://discourse.openehr.org/u/vanessap)
#### Post date: [12 August 2024 13:24 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/4 "2024-08-12T13:24:03Z")
Thanks for the push! I wasn’t aware of this initiative either. I will bookmark it as I will need this content soon.
---
### Author:  [@linforest](https://discourse.openehr.org/u/linforest)
#### Post date: [13 August 2024 01:06 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/5 "2024-08-13T01:06:44Z")
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.
---
### Author:  [@heather.leslie](https://discourse.openehr.org/u/heather.leslie)
#### Post date: [13 August 2024 02:33 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/6 "2024-08-13T02:33:01Z")
@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](https://discourse.openehr.org/uploads/short-url/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?
---
### Author:  [@linforest](https://discourse.openehr.org/u/linforest)
#### Post date: [13 August 2024 05:33 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/7 "2024-08-13T05:33:55Z")
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?
---
### Author:  [@linforest](https://discourse.openehr.org/u/linforest)
#### Post date: [3 September 2024 08:32 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/8 "2024-09-03T08:32:21Z")
> [@erik.sundvall](#):
>
> Clusters have been experimented with in the [clst archetypes](https://github.com/regionostergotland/Physical_activity/tree/master/proposals/2019-07-12_clst).
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):**
```auto
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)_:**
```auto
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>
>
>
}
}
}
}
```
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [4 September 2024 05:49 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/9 "2024-09-04T05:49:31Z")
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 [hellux (Noah) · GitHub](https://github.com/hellux) and his fellow students in a preceeding student project.
---
### Author:  [@linforest](https://discourse.openehr.org/u/linforest)
#### Post date: [4 September 2024 05:57 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/10 "2024-09-04T05:57:29Z")
@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.
---
### Author:  [@siljelb](https://discourse.openehr.org/u/siljelb)
#### Post date: [4 September 2024 06:19 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/11 "2024-09-04T06:19:05Z")
The units file [specifications-TERM/computable/XML/PropertyUnitData.xml at master · openEHR/specifications-TERM · GitHub](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.
---
### Author:  [@linforest](https://discourse.openehr.org/u/linforest)
#### Post date: [4 September 2024 06:28 UTC](https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983/12 "2024-09-04T06:28:00Z")
Thanks, @siljelb