In the thread below, Pablo asked whether Action should have as its data not just an ItemStructure but a History, like Observation. Does anyone else have evidence supporting this need?
A related question is: is there a need for an Observation type that only has one Event in it, i.e. one time-point? Obviously quite a few observations in real life, including 'patient story' are of this form. Our original motivation was to make all Observation data structures the same, hence the current data structures. Introducing more types makes code more complex and therefore error-prone, but generally makes data simpler/smaller overall. thoughts? - thomas On 13/02/2012 21:31, pablo pazos wrote: > 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 > <http://www.openehr.org/uml/release-1.0.1/Browsable/_9_5_1_76d0249_1140530578205_529440_4046Report.html>. > > 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<ENTRY> or a HISTORY<COMPOSITION>? > > > Thanks a lot for sharing, > Kind regards, > Pablo. > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical -- Ocean Informatics *Thomas Beale Chief Technology Officer, Ocean Informatics <http://www.oceaninformatics.com/>* Chair Architectural Review Board, /open/EHR Foundation <http://www.openehr.org/> Honorary Research Fellow, University College London <http://www.chime.ucl.ac.uk/> Chartered IT Professional Fellow, BCS, British Computer Society <http://www.bcs.org.uk/> Health IT blog <http://www.wolandscat.net/> * * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/5d1c932d/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ocean_full_small.jpg Type: image/jpeg Size: 5828 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120323/5d1c932d/attachment-0001.jpg>
