Hi Thomas, I think that a simpler single-event model would be very helpful, as very many observation archetypes will only ever require a single event. This complicates the archetyping and adds a layer of complexity to training. I like the sound of what Saso is doing whic is essentially to flatten out / hide the complexity, rather than lose it altogether and create a new archetype class. Not sure how this could be done in practice.
More controversially, I wonder if we need to rethink state and protocol, particularly protocol, given that we do already have 'summary' with in the history class which captures information pertinent to all Events. I increasingly feel that protocol is useful as a design directive but should not have semantic/structural meaning. We never search for 'elements under protocol' or obey firm rules like 'you never need to display items within protocol' . By all mean allow authors to express these kind of classifications against particular elements but they do not IMO need to be semantically or structurally hard-wired. There are stronger semantic arguments for State. Let the debate begin!! Ian On 26 March 2012 12:34, Sa?o Rutar <saso.rutar at marand.si> wrote: > 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@**oceaninformatics.com<thomas.beale at >> oceaninformatics.com> >> > >> >> To: openehr-technical at openehr.org >> Subject: Re: 13606 revisited - list proposal >> Message-ID:<4F6C87DE.8090004@**oceaninformatics.com<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<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<http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical> >>> >> >> > > ______________________________**_________________ > openEHR-technical mailing list > openEHR-technical at lists.**openehr.org<openEHR-technical at > lists.openehr.org> > http://lists.openehr.org/**mailman/listinfo/openehr-** > technical_lists.openehr.org<http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org> > -- Dr Ian McNicoll office +44 (0)1536 414 994 fax +44 (0)1536 516317 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com Clinical Modelling Consultant, Ocean Informatics, UK Director/Clinical Knowledge Editor openEHR Foundation www.openehr.org/knowledge Honorary Senior Research Associate, CHIME, UCL SCIMP Working Group, NHS Scotland BCS Primary Health Care www.phcsg.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/a94ad09b/attachment-0001.html>
