ErikSundvall
commented
4 years ago Discussions were initially in openEHR's Slack forum for modeling, then it was suggested that discussions move to this project's GitHub issues (as a test of an alternative platform) but discussions never took off after the initial posting above by Noah Hellman @hellux.
Now (september 2020) we'll try to restart discussions in openEHR's discussion forum at https://discourse.openehr.org/t/physical-activity-archetypes-exercise-steps-etc-from-apps-devices/983 instead, so we now close this GitHub issue)
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:
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;
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:
Cons:
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:
Cons:
Single-level specialization has been experimented with in the 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:
Cons:
Clusters have been experimented with in the 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:
Cons:
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: