Modelling an Archetype to record patient-identified activity limitations across time

[pascalbolla]

Hello everyone,

This is my first attempt to model an Archetype for an old and still very relevant outcome measure in the world of physical therapy and rehabilitation - The Patient-Specific Functional Scale (Stratford et al., 1995).

To use the scale the patient has to identify up to five activity limitations. Each is then measured over time on an 11-point scale.

Considering that each activity is specified only once and remains unaltered over time, is it best practice to describe / define the individual activities via free text (in a cluster) within the protocol and then reference the activities from point event data?

I couldn’t upload the ADL file, but the below screenshot should tell the story…

I look forward to your input.

Thank you all,

Pascal

Ref

Stratford, P., Gill, C., Westaway, M., & Binkley, J. (1995). Assessing disability and change on individual patients: A report of a patient specific measure. Physiotherapy Canada, 47(4), 258–263.https://doi.org/10.3138/ptc.47.4.258

[ian.mcnicoll]

Hi Pascal,

and welcome to our community.

I found this helpful via https://www.physio-pedia.com/Patient_Specific_Functional_Scale

I think you can probably simplify to something like this - Obviously the Activity cluster is multiple occurrence. I also wondered about adding an Activity Index count for each Activity to indicate e.g Activity 1, Activity 2 and to distinguish Addtional activities.

[pascalbolla]

Hi Ian,

Thank you for your response. I suppose my question was a more general modelling question that I think you answered and I also saw addressed in Archetypes like the ‘laboratory test result’. But let’s see if I’m on the right track. For that, let’s take the simplest form of a lab observation:

Name of test (string)

Value (number)

Here the name stays constant across multiple measures and the value is expected to change. So a normalised model for the above relationship across time might look like this (I’ll use json here):

{
  "nameOfTest": "lab XYZ",
  "entries": [
    { "date": "2025-10-12", "value": 120 },
    { "date": "2025-10-13", "value": 118 }
  ]
}

But based on your response and what I see in other Archetypes, we’re rather modelling for a simple array in which we repeat the constant (name of test) for each entry of the same observation:

[
  { "nameOfTest": "lab XYZ", "date": "2025-10-12", "value": 120 },
  { "nameOfTest": "lab XYZ", "date": "2025-10-13", "value": 118 }
]

Is that correct?

Thanks again for your time and input.

[siljelb (Silje Ljosland Bakke)]

@pascalbolla

a simple array in which we repeat the constant (name of test) for each entry of the same observation:

Hi Pascal, and congrats on your first archetype!

The OBSERVATION class, which is used for any information closely associated with a point in time or interval of time, has a repeatable EVENT structure within it. It’s difficult to see how it’s operationalised when you’re modelling the archetype itself, but it comes more to life when you put it into a template:

The timeelement is contained within the EVENT, but not displayed explicitly here. For a lab result the EVENT time is intended to be the time of specimen collection, while for your PSFS example it’ll be the time of assessment. As you’ve pointed out, if you only have the name of the test, the time of specimen collection and the result, it can be represented using a simple array. However if you want to add information elements from the Protocol section, that element will be contained at a higher level also containing the results array.

But a single specimen collection time could also be used for a number of different tests, in which case the event object will be more complex:

{
  "events": [
    { 
      "nameOfTest": "lab panel XYZ",
      "time": "2025-10-12T22:35",
      "analytes": [
        { "analyteName": "Analyte X", "value": 118 },
        { "analyteName": "Analyte Y", "value": 34.2 },
        { "analyteName": "Analyte Z", "value": <1 }
      ]
    },
    { 
      "nameOfTest": "lab panel XYZ",
      "time": "2025-10-12T06:43",
      "analytes": [
        { "analyteName": "Analyte X", "value": 110 },
        { "analyteName": "Analyte Y", "value": 30 },
        { "analyteName": "Analyte Z", "value": 3 }
      ],
      "confoundingFactors": "Prolonged stasis"
    },
  ],
  "pointOfCareTest": "true"
}

[heather.leslie]

In addition, the EVENT could be used to identify the ‘Initial’ baseline from subsequent assessments.

[siljelb (Silje Ljosland Bakke)]

Good point! For anyone interested, I’d recommend having a look at the HISTORY class documentation, which also contains the origin and a couple of other elements along with the list of EVENTs.

[pascalbolla]

Thank you all for your detailed responses. That has mostly answered my question.

So in summary, what I take away from this is that CONSTANTS (variables that do not change over time, yet are part of WHAT is observed), such as ‘Test name’, ‘Analyte name’, or ‘Patient identified problem’, are committed/stored as part of each EVENT data entry for a given Observation Archetype.

For now I’ll spend some time with the API to see how this looks on the data retrieval side of things before I model my way into a dead-end.

[ian.mcnicoll]

One thing to consider is that openehr always has entry data committed as a Composition , which reflects some piece of clinical work happening at a particular time. In this case it would be a patient recorded assessment. And it is more likely that the next assessment would generate a new composition. The assessment entries can be queried across compositions. As Heather and Silje have said, you can bundle up multiple assessments using the observation events structure but this is generally more applicable to events occurring over a short period of time.

[pascalbolla]

Ian, thank you for the additional comment. And thank you all for the warm welcome in the discussion group.

[bna (Bjørn Næss)]

Thanks for asking this question. As a former phsysiotherapist and with years of modelling experience I find this a relevant and useful modelling challenge.

As @ian.mcnicoll , @heather.leslie and @siljelb have mentioned the EVENT structure is great to model this.

What I also found interesting for this use-case is the, not so widely used, summary attribute on HISTORY. See: Data Structures Information Model

It’s defined as : *Optional summary data that aggregates, organizes, reduces and transforms the event series. This may be a text or image that presents a graphical presentation, or some data that assists with the interpretation of the data.
*
This could be a useful attribute to store an aggregated outcome for series of events. I am not sure if it is relevant here; but we could calculate and store a summary of all the events here.

I tried to add summary to an OBSERVATION archetype using AD. It is not supported as far as I can see.

This is the best I could do with some handcoding of the ADL.
NOTE: it is not correct - just for an illustration