On 31/01/2012 16:43, pablo pazos wrote: > Hi Thomas, I've added a proposal to the page on the wiki > http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model > > 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. 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. 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. 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. 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. 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. 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 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'. 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. Anyway, these are my thoughts for now. Let's continue the discussion, and continue to work on the wiki page <http://www.openehr.org/wiki/display/spec/openEHR+2.x+RM+proposals+-+lower+information+model>. - thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20120205/18c19726/attachment.html>
