Observation Archetypes - different data for different events

I’m looking at Observation archetypes at the moment, specifically those that specify specific events within the model.

Examples being

Can anyone point me toward an archetype with defined events, where the data captured at each event is different (or at least not the same for each event)?

I’m not entirely sure I understand what you mean. Do you have an example of a concept where this would be a requirement?

I thought something like Body weight which has birth weight as a different type of even constraint from the standsrd event.

@siljelb this is not about requirements but about the art of the possible.

Consider Apgar score, it defines a series of events that cater for the data capture at different time points.

Now looking at the ADL, we see the following

So the data specified for each time point refers to the data structure used for the first time point.

I am interested in whether there are any current archetypes where different data structures are used for various time points.

1 Like

See Body Weight

The differences though is just in the EVENT constraints not in the data structure within each event.

I’m not sure that we can actually have seperate structures within each event - it is certainly not supported in tooling.

1 Like

Yes, I don’t think we can have differing content within each specified event definition either. I don’t think I’ve ever come across a requirement for this before, but maybe it’ll pop up in the future.

What I have come across though, is slightly differing requirements between different ACTION careflow steps. An example could be ‘Scheduled date/time’ only being relevant in the ‘Scheduled’ careflow step.

2 Likes

Could this be a possible use case?

An Observation where you could register either

  • A series of POINT_EVENTS with their needed data structure

or

  • An INTERVAL_EVENT that summarizes the data in a time interval, with a different data structure

So that any of the two alternatives could be used depending on the use case. Technically this is a totally valid archetype. We can edit the ADL and it is parsed without issues.

I’m not sure I get the requirement.

As Silje says, in ACTION archetypes, there might be elements not necessary or even correct for all pathway steps. There are examples of this in some ACTIONs.

For OBSERVATIONs as Body weight where the EVENT only gives the context to the same elements, there is no need to have different data elements.

If there are a need to have other data elements for different events, it might not be the same concept? It might be an EVALUATION instead.

Example: Body length, measured during progression of osteoporosis, can show reduced body length over time. This reduction should be calculated by the events, and stored as a finding in Problem/diagnosis or some other EVAL archetype, not in OBS.Body length.