Hi Thomas, Indeed, our practice confirms the need for a simpler form of single event observations. We are compensating for this with our Java TDO generator that detects history instances with event count constrained to single and merges a history and event objects into one event-history object that sort of represents a union of both classes. This way our developers end up with a less boiler-plate code to deal with and the rm model is preserved.
best regards, Saso Rutar Date: Fri, 23 Mar 2012 14:25:34 +0000 > From: Thomas Beale<thomas.beale at oceaninformatics.com> > To: openehr-technical at openehr.org > Subject: Re: 13606 revisited - list proposal > Message-ID:<4F6C87DE.8090004 at oceaninformatics.com> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > > 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 >
