Timing in the real world, openEHR and FHIR

[heather.leslie]

@ian.mcnicoll

'this statement remains true at ‘yyyy-mm-dd’,

If you are responding to the assertion that the data is correct, without changing the data at all, then agreed and it is more ‘Date reviewed’ (although this is not currently modelled in any archetypes but probably should be). The intent is not the same as ‘Last updated’, which (rightly or wrongly) is deliberately intended to be visible as a reviewable data element in most EVALUATIONs because if we don’t have it there, clinicians want it. It is effectively a duplicate of the RM date created primarily because of tooling issues re revealing RM attributes.
If the data is reviewed and updated, then both ‘date reviewed’ and ‘last updated’ would be aligned.

[heather.leslie]

@thomas.beale

• how to represent ‘date asserted’ the first time something is recorded e.g. a Dx;
• how to represent something like ‘date confirmed’ later on, to indicate that the thing was reviewed and found to be still present / true etc;
• how to represent that things have changed when you review.

• The date/time an EVAL is asserted is usually the date it is created.
• If we need other dates (esp those in the past), like when a diagnosis was clinically recognised, then this is modelled explicitly. If it was diagnosed today then the record creation date and date clinically recognised are identical. If it was diagnosed 20 years then there would be a 20 year time difference between today’s record creation and date clinically recognised.
• If there is a requirement to review existing data and assert that it remains correct so we can get some clinical estimate of how up-to-date the data is, eg tobacco smoking, we can currently only identify when it was last changed/updated; not when it was reviewed, found to be correct, and so left unchanged. The use case is where there may be a requirement to check smoking status once a year for accreditation purposes etc. This assertion that a review was done is currently not supported in RM or modelled explicitly in any archetypes - RM would be ideal, but only if it can be exposed to clinicians in tooling for review etc.
• If we need to see how things have changed over time, I’d assumed it was already supported in the versioning available - this is relevant for all EVAL archetypes used as summaries, that grow and evolve over time.

[heather.leslie]

@thomas.beale

Semantically this makes the Composition look more like a persistent one, which is appropriate if we think about it, since the reviewing activity has the effect of maintaining the currency of the original information - e.g. an asthma diagnosis from 5y ago or whatever.

Makes clinical sense, but is it over-engineering? Maybe a IRL discussion might be helpful for clarification

[heather.leslie]

ACP is a rather special case because of it’s legal ramifications and potential for sharing/viewing by others outside a single clinical system, hence the inclusion of the date when it needs to be checked again, and this may be different to the Expiry date.
Most other things that need a review would be managed with system-wide reminders etc.