Let me try to be as brief as possible. (narrator: he failed)
I’ve been thinking about the temporal (allow me to talk fancy here) aspect of clinical data, and I have some ideas going all the way back to my PhD at UCL.
I could not entirely crack some of the challenges of the time centric representation and processing of clinical data back then, and I’ve been working on it ever since in my free time (which I have lots, just like every other member of this community…)
My problem is, I don’t know which subset of clinical data has significance as values that change with time. Some data becomes extremely time sensitive in a particular context (when the patient is in the A&E with a suspected acute heart condition), and less sensitive in others, i.e. just the latest status (snapshot in time) is sufficient.
The more I think about it, the more data I see as time sensitive, but it is so subtle. Chronic conditions and age (demographic) changes that nature of data, and so does other things.
This is a challenge for me on the technical side of design: say, what subset of models in CKM have this aspect, i.e. that a clinician would like to see their variation in time, and in what circumstances? In (yet) other words: is this something I should promote to first class citizenship in my computational thinking, or is it something that I should consider as “computed when necessary”. Making it first class means it is an aspect of computation every time openEHR data is processed, for whatever the use case is, and leaving it on a need-to-compute basis leads to a different technical approach.
So my question to those who work on the models is: which models do you see having a time element, and under what circumstances. Big question, so I’m not expecting a large volume of writing in response, but even a high level elaboration would help me adjust my perspective.
Interesting question. I find it hard to come up with a helpful answer. But I would be interested to talk. Either via zoom or live in November. You would have to get me up to speed with your work though.
My first idea would be that all data is time sensitive. But the significance can often only be determined at retrieval.
I may be completely missing your point here, but here’s a quick brain dump:
In openEHR terms we have three main (clinically oriented) structures where the temporal aspect is central, ie they contain mandatory time structures:
COMPOSITION class (when did this thing start and end)
OBSERVATION class (at what point(s) in time or during which interval(s) of time was this thing observed)
ACTION class (at what point in time was this thing performed)
In my opinion, you can pretty clearly see which clinical concepts are in their essence time sensitive by looking at the class their archetypes are modelled as.
There are of course concepts modelled as the EVALUATION or INSTRUCTION classes where time is also relevant, like Problem/diagnosis or Service request. It often matters at which time the symptoms of an illness was first observed, or at what time a particular clinical service must be performed by. But you can record them without including those times, and they still make sense. A record of a pulse rate (OBSERVATION) without the time it was observed is useless data, because it changes every second. A record stating that a pulse observation has been performed (ACTION) without the time it was performed is useless data because you don’t know which planned observation was performed.
There are some archetypes where this kind of assertion breaks, like the “Exclusion” (EVALUATION) archetypes. An exclusion (of, say, a particular allergy) is by its nature time sensitive because it could change at any time and it’s therefore important to know whether it was asserted yesterday or ten years ago. These archetypes have been on the todo list for remodelling as OBSERVATIONs for a while now, and it’s only due to lack of resources they’re still in the CKM as EVALUATION archetypes.
Thanks @siljelb You’re not missing the point. I like the way you’re using the RM type semantics as hints here. I’m more interested in the case where a clinician wants to see how data based on a clinical model changes in time, rather than the timing of the data having significance. I think the RM type based thinking is a good starting point/hint (that did not occur to me ) but I was wondering if there are obvious observations that are mostly traced from a point of view of change-in-time.
I think it’s hard to classify clinical data like this, as @joostholslag says, it is dependent on the context. For example, my GP practice sent me an SMS a few months back, asking for my blood pressure measurements as part of keeping track of that value with regular measurements. That was not the case until I “matured” beyond 45
I’m keen to keep my motivations away from this thread because tech stuff is catnip to clinicians and I’d rather they stay focused Having said that, I’m trying to see if its worth designing some technical solutions “temporal first”. As in: clinical values are all assumed to change in time, some change less than others, with the lower limit being 0 times, but they all do. That kind of design addresses some clinician requirements much better than putting together a “change in time” view of data on demand, but then you pay the price of that design in every use of data even when only some of the data fits this definition.
Hi Seref, I might still be a little confused about your exact question but if it is , are there particular kinds of data that clinicians might want to e.g display as a time-based chart, then I’d agree with @Silje that basically we could be talking about any OBSERVATION, well beyond lab, vitals etc to include things like scales and scores. I think the OBSERVATION calls handles this pretty well but I do think we will be under increasing pressure to access individual ELEMENTS via SNOMED terms esp. via the lens of a FHIR observation search i.e "give me a time series of ELEMENTS within OBSERVATIONS which are coded with SNOMED CT 1234567 (Pulse rate). i.e. agnostic of the exact parent archetype. If you are looking for performance optimisation, that might be worth exploring.
I’m interested in template and archetype level answers, RM is just too low level, which is what I was trying to express when I responded to Silje. The search criteria is just a detail, the question is “which clinical concepts end up as time series more often than others”? The feedback so far makes me think that the answer is “it depends” so there is no clear answer I think. Not unexpected.
As modellers, we think the other way - the clinical requirements are actually the critical ‘it depends’ factor and from the requirements we understand that time expressed in ‘this way’, ‘that way,’ or ‘these ways’, so we can choose an appropriate class that allows that representation.
OBSERVATIONs are easiest and relatively simple to identify - state + point-in-time and intervals or time or time series. INSTRUCTIONs are pretty self- explanatory. ACTIONs are also easy to identify and hugely difficult to model well. EVALUATIONs are the enigma - for a long time they’ve been the ones that we use for ‘the rest’ but there are equally important patterns of use related to summary concepts that are becoming increasingly obvious and include even more variation in approaches to recording timing attributes.
Thanks Heather. Just to clarify, my “it depends” was referring to clinical requirements, but it was nowhere as nearly subtle as your angle. Your explanation is fascinating to me but I want to understand I get it right: are you saying that how the time element of the clinical concepts (change in time, point in time) etc is a determinant of which RM class you choose? If that’s the case, then it is a much more significant determinant of semantics than I thought it was for modelers. If that’s not the case, I’d appreciate some education.
My conviction from a tech point of view stays the same overall though, that it is hard to develop a sense of the “frequency” of cases in which clinicians are interested in clinical concepts represented across a period of time. I’ve always been at peace with the idea of not being able to formalise/generalise what you do beyond a certain point at the technical level, and I think that threshold in my head is significantly lower than that of what most of my tech. colleagues have in theirs.
Nonetheless, thanks for the insightful response and the time you took for it.
Absolutely - usually OBS. But actually, it’s the EVALs that are much more interesting. I’m very slowly writing a paper to describe my thoughts about the EVAL patterns - evolving accidental academic here . Not rocket science, but clear demarcations observable between types of EVALs, based on timing.
This can only come from research into EHR use, I would think and would vary depending on the clinician and the domain. Clearly the vital signs domain is the most frequently used, but still enormous variation between ICU machines that go beep and community care etc.
Aggreed 100%. It is also kind of why I made the point in this discussion that going from RM up to the 2nd layer of modelling or even to the templates and the application itself is not a classification criteria with enough specificity. As I said, same application can switch to a “change in time” of a data point in a model for reasons related to demographic (again, me maturing with years…) I have more than 40 updates to a single composition because that’s the number of updates a pathology system sent us for a single HL7 V2 message. Al l those versions may urge one to think that this is something that may be valuable to clinicians as a value plotted against time, but it’s only the last version they’re interested in
Well that’s even more interesting, because we always had some sort of “design patterns” lingo to fall back to on the software side of things, but I did not see modellers having that domain specific language to refer to patterns themselves. Very interesting stuff, outcomes from that would be interesting too: will it help more efficient collaboration or will it allow you to have more efficient and faster fights like it allows us on the software side (of course you’re not supposed to use BLATROFOO pattern there, everybody knows that!)
Thank you for this observation. I’m acutely aware that the tech community has been advocating for more formalized modelling patterns for quite some time, leading to an unfair sense of judgement on Editors, who are operating in a hugely complex, incomplete, inconsistent and nuanced knowledge domain. While scores & scales may be simple, coherent documentation of physical examination findings or a systematic approach to recording lab or imaging results has been largely uncharted territory. Software engineers may operate with clearer binaries, but clinical medicine most often does not. Patterns that have worked across previous archetypes can be easily broken by an outlier use case which we then need to revisit and reinvent. Documentation is therefore not straightforward nor, despite our experience, have we found a simple way of recording it, except through the archetypes themselves!
Your query is valuable because it prompts us to articulate the intricate blend of art, skill, and difficulty that goes into our work. There’s a level of nuance, commitment, and attention to detail involved in creating a coherent data ecosystem that is often overlooked, particularly by those on the technical side.
) but I was wondering if there are obvious observations that are mostly traced from a point of view of change-in-time.
. Not rocket science, but clear demarcations observable between types of EVALs, based on timing.
(of course you’re not supposed to use