As part of my work with the US VA, I have done an analysis of the HL7 FHIR ‘choice’ construct - choice is the little ‘[x]’ you see in a FHIR resource where there is a choice of data types (example: look for onset in AllergyIntolerance). There are various problems with choice in general (my discussion of this), and one of them is that different groups in HL7 create very similar but not identical lists of type choices, for what is probably the same semantic intent.
Anyway, my interest here is to look at one of the types of data element that creates a lot of choice structures in FHIR - timing. Now, timing is actually hard, and we don’t model it right in openEHR either, as we are discovering in Task Planning.
I have done some modelling in Task Planning to cover some of the timing semantics we need, but the above FHIR analysis was a catalyst for looking more closely at how to model various categories of time representation. You will see some UML diagrams at that link above for these.
However, independent of this, those in archetype-land (at least @ian.mcnicoll, @heather.leslie ) have done more long-term thinking and modelling on timing.
I would like to propose a conversation on ‘modelling time’ and deriving a better solution that:
includes some reference model level support;
makes it clearer what would still need to be in archetypes;
gets closer to a recommendation for HL7 on how to fix this bit of FHIR.
My current view is that there are the following categories of ‘timing’:
Single specific point or interval in time of an event or state
When an event occurred (past) - characterising multiple ‘occurrences’ / pattern of occurrence
This is very interesting indeed. Timing is one of those things we did struggle a lot with, but I believe we got mostly right the models we made in relation to the medications modelling work a couple of years ago. I’d be interested both in hearing about the things we aren’t getting right, and in participating in further discussion and work about this.
My ‘Time Archetype’ consists of:
Time is an interesting concept in Archetype modeling.
Kinds of Time I discern: 0- System time using the data type Time 1- Absolute time in an archetype: a point in time, or a fixed range 2- Relative time in an archetype: a period in time relative to an origin. The origin can be anything: an observation, etc… The relative time can have a specific meaning: season, day of the week, birthday. And one needs to qualify relative times: such as: before, after, etc.
A related interesting topic is naming patterns in time.
We certainly need to manage the absolute v relative distinction. Have a look at the first UML model; it does some of this. The second model (the Age-related one) also does this. My models so far are not complete, and might not cover all aspects of absolute v relative, so it’s a good point to remember.
System time (v world time) is to do with the meaning of attributes in the model. E.g. AUDIT_DETAILS.time is documented as a system time, not a world time (like Observation.data.origin or similar).
I don’t know if we have any problems in the archetypes - I am not up to date on them - what we don’t have is proper support in the RM. If we did, it might simplify the archetypes, and it will certainly be useful for TP.
So, first Q: would you mind posting the links of the time-related archetypes here, so we have a reference?
These archetypes are made primarily to record the timing of planned healthcare interventions, for example medications or services. As these are usually divided into “timing patterns within a day” and “timing patterns outside a day”, there are two of them:
Since these two patterns often interact, these two are connected with each other through the Therapeutic direction and Dosage archetypes for medications and other similar therapeutic interventions, and Service direction for healthcare services.
So I think these two archetypes are ‘future’ timing, i.e. my category 4. Do we have a model for expressing occurrences in the past, e.g. history of migraines or similar? That is category 2 in my original list, and causes a lot of complexity in FHIR (see the wiki page).
We would just use Symptom sign and nest the prior episodes, as it is entirely possible that there is more information required about prior episodes than just the date(s).
That’s my worry about the hunt for some kind of perfect ‘timing’ approach - inevitably the details of what you are timing tend to be intermingled with the timing itself.
I’d certainly like to see us handle age/dates and textual/coded ages like ‘at birth’, in childhood’ , a little more seamlessly but I’m not convinced there is a major issue here, not in openEHR-land , at least.
There might not be any issue in openEHR, other than what we need in Task Planning / GDL - I don’t mean to imply that there are any problems elsewhere. My initial idea was just to have a look at timing in FHIR, timing in our archetypes, and then consider what we will add to the openEHR Foundation models, as well as potentially make suggestions to HL7, if we see gaps.
I have had a quick look at the blog on FHIR choices and I’d certainly split the issue into representations of current/past dates (and proxies for that, like age or ‘at birth’ and future timings.
I think the use of the FHIR Timing datatype in e.g Observation is a mistake, it is not terribly different from our timing archetypes thought I prefer our clear split of daily and non-daily. In due course we might be able to move that into the RM. So far it has stood up well for complex medications but I’d want to wait until it has been more rigorously tested in other contexts such as service direction instructions.
Finding a more elegant way of doing past date(s), human age (which I think does deserve a specific datatype) and textual proxies for actual events would be worthwhile.
Within archetypes such as Symptom/Sign, Problem/Diagnosis we model past dates using DV_DATE_TIME set to allow partial dates.
Also ‘Last updated’ modelled on almost every EVAL that should be part of the RM. ‘Last reviewed’ is also an interesting date, especially from a medicolegal perspective.
We try to avoid modelling ‘age at…’ because humans/registries/legacy systems do it but it causes potential conflict/complexity if others record the same thing as a date/time, although if they could be linkedrelated somehow it might be more viable to model either way. There are very few data items that are best modelled as ‘age at’ or ‘as a child’ etc.
What does ‘last updated’ mean, if it doesn’t mean ‘last reviewed’? Hopefully it doesn’t mean what it says, since that is already part of the reference model - every committed data set (Composition) is a new version, with its own AuditDetails object, containing all the necessary audit information, including date time.
A clinician can review the status of something, find it’s ok and not change anything of the data record itself, or use that information trigger an action or event etc.
There is potentially medicolegal import to recording that it was reviewed, found correct and unchanged. It can trigger the timing for the next review date etc.
We often model ‘Last updated’ so that it is available outside of the RM, especially for sharing via FHIR messages etc. This is why we need more of the RM available/visible/represented in the tooling.
Would you normally add a note or some indication that ‘X has been reviewed, no changes found’ or similar?
Not sure I understand this bit. Depending on how data might be shared via messages like FHIR or other means, the Version meta-data, including the audit may be shared. The audit indicates when that info was committed to the EHR, i.e. became visible in the shared information environment. Does the ‘last updated’ attribute correspond to this idea, or some other idea of ‘update’?
If we can tease this out a bit, then I think we can clarify if anything extra is needed in the RM.
I think the basic requirement is to be able to say at Evaluation level that 'this statement remains true at ‘yyyy-mm-dd’, irrespective of the parent composition, particularly when it might need to be consumed, used, outside that parent composition, whether by querying, referencing or cloning.
I thoi=ink if it as ‘Date asserted’ , which was considered but reckoned to be too “informatician speak”, which I understand.
It is the Evaluation equivalent of ACTION.time or OBSERVATION. origin, in the sense that while a composition start_time is normally a good proxy, that does not always apply. In the case of an Evaluation it recognises that the ‘truthiness’ of a particular Evaluation statement may need to be re-affirmed over time.
Aha - ‘date asserted’ is a lot clearer. For me ‘last updated’ is pure IT-speak! Date asserted is semantically what you are talking about (in my understanding so far).
So the needs are:
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.
For the first, an RM attribute EVALUATION.time_asserted would be appropriate (we tend to use the word ‘time’ to mean ‘date/time’ in models).
For the latter, I would initially imagine that each time a review was conducted, a new EVALUATION was created representing ‘review’. This would also have its own time_asserted (since it’s another EVALUATION), and it could have a LINK pointing to the original EVALUATION.
This is a bit clunky, and possibly a better approach would be to add something to the EVALUATION class in the RM, such as reviews: EVALUATION[*], i.e. a direct connection to a chain of subsequent review Evaluations. This could even be a new class to make it a simpler class, e.g. EVALUATION_REVIEW. Either way, this would allow you to re-version the original Composition for each review, and add a new ‘review Evaluation’ to the list, with the new date/time. 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.
Review due date makes sense for an ACP, but would you ever record such a thing for a diagnosis? In my understanding, ‘review’ normally relates to a managed condition, e.g. pregnancy, most chronic diseases etc, so I would expect a ‘review date’ to be recorded in a care plan or similar, rather than in Evaluations generally.
So it seems to me that ‘date asserted’ (i.e. what is currently called ‘last updated’) could make sense in all Evaluations globally, but ‘review date’ only in those that document things that act like plans or directives or similar.
