Persisting a duration or "time since" related to an observation

We need to calculate the “time since treatment” when a questionnaire (represented by an archetype ICHOM LPC EPIC-26 Questionnaire (on Apperta KM)) is completed.
The date/time of questionnaire completion and the date/time of treatment are both recorded in the template (in different archetypes), “time since” would be a calculation.

We have 2 uses for the data - 1. Clinical use (data displayed to users, with trends showing “time since treatment” on the x-axis) and 2. Storage in a registry for research use.

Why not just perform calculation at use?
I realise in both instances, the calculation can be performed at use - but I think it would be easier at the point of use to have the duration persisted as data, e.g. if you wanted to retrieve all questionnaires completed at a particular duration since treatment, the query is much simpler than if a calculation must first be applied, and also if the questionnaires are ever stored separately from the “date of treatment” archetype - then this duration would be persisted with the questionnaire without ever needing to know what the date of treatment was (e.g. complete questionnaires transferred to local EHR systems / GP systems)

Main question = is this needed.
Heather Leslie has suggested ways it could be done (see below) but now the bigger question is - does this really need to be done. Anybody else with experience of this much appreciated.
I see something similar discussed in this post:
Persisting “% change” of an OBSERVATION - Clinical - openEHR

Solutions from Heather Leslie:

So, a couple of initial thoughts if we do need to persist the duration:

  1. IF clinical requirements identify this to be a common use case related to this EPIC-26 archetype or multiple questionnaires/assessments then it may be useful to create an archetype to support a generic documentation pattern that works for all, independent of any specific OBS/questionnaire archetype. We could consider creating an OBSERVATION archetype that defines the generic start point trigger/event (not necessarily a date/time), endpoint trigger/event (not necessarily a date/time), the duration between the start and end points (DV_DURATION) and a LINK to the instance of the OBS being screened/measured/assessed. Frankly, I have no idea if this is a real requirement or not at this point.
  2. At the other extreme, IF this is a local-only use case and only ever applicable to this single archetype, it may be enough to build a local CLUSTER archetype that captures the timing information and nesting it in an Extension SLOT - either within the OBSERVATION.ichom_lpc_epic_26 OR the COMPOSITION in which the ICHOM is being recorded. It is ugly, messy, non-standard, but worth considering the cost vs benefit.
1 Like