’
Maybe consider adding another attribute to the COMPOSITION class to uniformly record the visit information? Since it feels much better integrated with the system and the visit identifier is mostly just another context data point.
We can certainly discuss this, although it was always assumed that that was the purpose of EVENT_CONTEXT.other_context. But if we think we can standardise visit info, more attributes could be added to EVENT_CONTEXT.’
Is this pursued? This is a basic requirement and would be really helpful if this is added in the COMPOSITION class.
Please correct me if I’m misunderstanding the requirements here, but I still think you’re making things harder for yourself than necessary. The inclusion of a total score implies that each possible response to a component question has a score associated with it. I’d model this as one OBSERVATION archetype specific for this questionnaire, like this: openEHR-EHR-OBSERVATION.test_questionnaire_score.v0.adl (3.0 KB)
That is definitely an alternative option, which I have seen used - use a CLUSTER archetype to record any common identifiers for a visit or episode, and plug them into event context in each related composition. There are arguments for both approaches.
FOLDERS probably wins as you have more potential groupings e.g this composition is in an admission episode folder but also in a Diabetes folder.
I agree with Silje that it feels as if you might be over complicating - can you share any of the original documentation or prototypes?
I don’t think I have ever linked back score components to ‘source data’. There is nothing technically wrong with that of course, and on occasion it is perfectly correct but it does land a maintenance burden if one or other composition needs to updated.