Hi Thomas,
Sorry for the delay, I’m working on several projects right now and have little time to follow discussion here.
I’m also thinking about the ENTRY model, to lift up the data/description attributes from all entry subclasses to the ENTRY, to have a ENTRY.data:DATA_STRUCTURE attribute, so all subentries could define the data as ITEM_STRUCTURE or as a HISTORY.
We did think about this a long time ago, but it did not seem useful. But I assume you are thinking of doing it because you want to make ENTRY a concrete class which could have ‘any’ structure.
Nope, is because I see a common pattern on concreate ENTRY subclases.
In theory doing this breaks a basic modelling rule, which is that a superclass whose descendants define the possible data space should not itself be concrete.
I think this is not the case, having a ENTRY.data : DATA_STRUCTURE is in fact a more specific ENTRY class, but is still a generic one that could be specialized in many ways. In my (maybe biased) experience, all subclasses from ENTRY would make use of this attribute since a structure is needed to record information.
The argument here I suppose is that we want to build in a 13606-style ‘uncommitted’ kind of ENTRY. In fact we already have this - it’s currently called GENERIC_ENTRY. This doesn’t get used at the moment (although it has been there for years), and if we want to make it a subtype of ENTRY, that could be done. The main thing to solve I guess is the conversion of any of the specific openEHR kinds of ENTRY into a generic ENTRY structure defined by 13606. This can actually be formally specified by an algorithm. It doesn’t require that the parent abstract ENTRY become concrete either. I am unclear if there are other reasons to make the ENTRY parent type concrete, to mimic 13606 ENTRY, rather than simply move GENERIC_ENTRY to be a subtype, which seems more obvious to me.
Maybe to have the flexibility to define ACTIONS and other entries to have a data attribute of class ITEM_STRUCTURE or HISTORY to track time of events instead of inventing DV_DATE/DV_DATETIME ELEMENTs on ACTION/EVALUATION/INSTRUCTION archetypes is a good idea. What do you think?
Well then I think we risk making the model ambiguous, and different people will use such flexible structures to do the same thing in different ways, which was the thing we were originally trying to avoid.
I disagree here, the model semantics could be defined in the specs. My argument is that we are giving a more flexible IM is adding flexibility (not ambiguity) to archetypes, and giving knowledge modelers more options. Then, when they create a concrete archetype, there is no ambiguity because an archetype models a concept in one way, and if abstract classes are used in archetypes, the archetype needs specialization to make is usable on a real environment (software can’t instantiate abstract classes, and could not make the decision between using subclass A or subclass B).
The HISTORY class is very nicely designed to represent complex time-series data that has the same protocol and was captured in an uinterrupted series. It does not try to model sequences of different types of data - in that case, you just have multiple observations.
I totally agree.
It deal well with point values, averaged interval values, max, min, sample compression and a few other things. But it’s no good with a succession of different kinds of patient events. Any such timeline for that kind of thing has to be constructed post-hoc, when the actual events have already occurred.
That’s the model semantics that should be defined on the specs. Knowing that, not misuse should happen. In the other hand, tools should not permit this to happen, and this could be implemented as semantic validation of RM instances (BTW this should be done with the current model also).
I can see a theoretical argument to wanting HISTORY in ACTION, instead of just a single point time, but in practice, noone has ever been able to come up with an example where a series of ACTIONs needs to look like a structured series, mainly because ACTIONs usually need to get recorded when they are done.
IMO ACTION.time:DV_DATE_TIME could have the same semantics as ACTION.data.events[0].time, if ACTION.data:HISTORY and events[0]:POINT_EVENT.
The easier example is a repetitive INSTRUCTION like “give 5mg of XXX for 10h every 30m”:
- The ACTION would register the same information structure
- The proposed POINT_EVENT of the ACTION could record the information like the current ACTION.time attribute
- There is a series of ACTIONS recorded for the same INSTRUCTION (instead of creating one ACTION instance for each XXX administration, one ACTION could handle all the information, time series and data, for all the susbtance administrations for the same INSTRUCTION/ACTIVITY).
For example, a regular IV drug administration could in theory be represented by an ACTION with a HISTORY, each of whose events described the action (say: admin Morphine 20 mg IV) but to achieve this you would have to wait until all the administrations were done before writing the data. So for some hours it would look like no drugs were being administered, then a long series of them would suddenly appear in the EHR stretching back… days?
I can’t see the difference with the current ACTION model: the ACTION could be created when the administration starts, and the date/time of that event could be written in INTERVAL_EVENT.time attribute, and when the administration ends, the duration could be written in the INTERVAL_EVENT.width.
Maybe I’m missing something here, but that’s whay I understand.
I am not saying ACTION is perfect - there have been suggestions for example that an ACTION + link + OBSERVATION structure should be available for when the prescribed ‘action’ was in fact a new observation, such as ‘check patient reaction to drug’.
It would be nice to discuss this proposals with more members of the community. I’m not saying we need to do the changes, what I say is lets discuss if we can improve the model in some way, analize the pros and cons, and write down a decision. I mean: we need to try to not leave these kind of discussions die on the maillist, this things are valuable assets that could be explored/exploted in the future.
Another question of time comes up with EVALUATION - e.g. the diagnosis archetype. This is full of times, and tries to follow a disease course model. Currently there is no RM class for this, but if a standardised temporal disease model were agreed across medicine, I suppose there is no reason why not. But it also is not a simple HISTORY - it is more ‘bumpy’… and I don’t know if there is any agreed standard model of this.
Maybe is something like a HISTORY or a HISTORY?
Thanks a lot for sharing,
Kind regards,
Pablo.
