For historical interest, I originally designed the OBSERVATION history structure to work for any observation, from one to N events / samples. From a software development point of view it is nice because you just need one piece of code, and it will handle a single point observation, or 5,000 1 minute samples of some observation.
I underestimated the annoyance value of those long paths for the many Observations that innately only ever have one sample (which is of course the majority of Observation types, but might not be the majority of data, since today we have more devices than ever generating time series Observations).
I have since come up with a pattern that is not quite as elegant from a software point of view, but does shrink paths, which has some value, especially if you get into AQL, GraphQL and such things.
Ok - we seem to have a high degree of consensus on adding time_asserted to EVALUATION.
How do people feel about adding it to the ENTRY class, so that it could be used (optionally) on any ENTRY sub-class?
I can certainly see the value in using this with INSTRUCTIONS, ACTIONS and ADMIN_ENTRY. Iâm not so convinced for OBSERVATIONS but I cannot see the harm to include ,as long as time_asserted is optional.
ACTION already has a time and this attribute doesnât add anything to OBSERVATION, since it already has itâs timing pattern well defined by the HISTORY, so I donât think ENTRY is the right place, specially if the name is time_asserted, which is related to the EVALUATION concept.
The argument for putting it on ENTRY is that there is one place to obtain the âclinically effectiveâ time of any ENTRY subtype - super-easy for client programmers / apps.
it will also be available as a directly queryable data field by AQL and other querying mechanisms
The argument against putting it on ENTRY is that itâs a duplicate field for ACTION and OBSERVATION, and to be valid, the correct other fields MUST BE COPIED IN at data create time. Needless to say, without a formal validation mechanism (e.g. in all CDRs) itâs easy for this not to happen, and for the field to be not populated, or wrongly populated. Making it happen properly could be achieved by the server, which could overwrite that field with the correctly computed value, but this is obviously âspecial processingâ.
NB: it would need to be a mandatory field to be useful - since the whole point is that itâs âalways thereâ.
The alternative is to define:
time_asserted on INSTRUCTION, ADMIN_ENTRY and EVALUATION
a function like effective_time() or similar on ENTRY, that is redefined in the subtypes to return the appropriate field, e.g. OBSERVATION.data.origin, 'ACTION.time` and so on.
The effective_time() function acts at a specification level to define what its value is from within the various ENTRY types and at an implementation level to actually compute the correct value (avoiding copying errors, as per above). HOWEVER: the latter does imply instantiation of programmatic instances of the relevant classes, in order to execute the function. In implementations that want to get the ENTRY.effective_time field value without doing this, e.g. via straight AQL querying or similar, something extra has to be done - either it is created as a derived field in the DB or some other trick, possibly stored procedure.
The need to have âderived fieldsâ like this that are visible to querying but not stored in the data instances per se is a generic one, and is not handled well by todayâs programming or DB technologiesâŚ