Hi. Several comments:
> We put it in because Grahame Grieve had identified a use case where there > was something like an image that summarised the data in the time series in > some visual way. Right. But had I know then what I know now, I would've held out for a less limited summary that could contain structured data summarization of the series. > Protocol' has a clear purpose and gets used for that purpose as far as I can > see in most archetypes: it contains the method of performing Observation / > Evaluation / Instruction etc Umm, but how do you handle the situation where data produced by the observation is structurally related to the protocol? The NEHTA pathology and radiology archetypes have data in the protocol for this reason. > The question of display I don't see as important > the minute we start sliding toward undisciplined data models, we start > heading back toward the non-computable data we have today Really? Because we know better than the people who collect and use their data what they need? I think that sometimes we actually do, but nevertheless this is very slippery ground. There's a reason why we have what we have today. As for display, data is no good unless it is displayed... Grahame On 27/03/2012, at 1:23 AM, Thomas Beale <thomas.beale at oceaninformatics.com> wrote: > > > Indeed we had something like this in Release 0.95 of openEHR - see from the > old spec. This HISTORY model worked badly for multi-valued data. > > <ebgbhgab.png> > > > However, if we are going to make a change, I think the correct model is not > just to add a different variant of HISTORY but a different variant of > OBSERVATION, with a single EVENT. This might be called SINGLE_OBSERVATION or > similar. Note that the EVENT could still be a POINT_EVENT or an > INTERVAL_EVENT. > > The reason we defined the current model with the time-series is that it means > software is simpler: there is only one model of all Historical (i.e. > observation) data: a History of Events. If we make the change we are talking > about here, the software becomes more complicated, and the data become more > varied, but overall, smaller. Also, archetype modellers might see the choice > of an explicit SINGLE_OBSERVATION as being more obvious for some Observation > types (tools should have supported this anyway from day 1, and just built a > normal OBSERVATION, but this wasn't done....) > > So what we are talking about are essentially differing optimisations - > greater software complexity, greater data variation, smaller data versus > simpler software but (slightly) less space-efficient data,. I personally > don't mind too much which way we go here - adding a single-event OBSERVATION > type will fit well in the 'clinical investigator model' ontology which > underpins the openEHR Entries. Many archetypes, including all patient story & > POMR 'subjective' Observations are of the single-event type. > > I don't think we should be pulling apart the rest of the model semantics > though (lower data structures are a different matter; see my other posts). > 'Protocol' has a clear purpose and gets used for that purpose as far as I can > see in most archetypes: it contains the method of performing Observation / > Evaluation / Instruction etc. If this is not being done, there is a problem > in the modelling. The question of display I don't see as important. What is > important is that protocol doesn't change the meaning of the data+state in > any routine data situation (e.g. just show me all the arterial BPs) . It can > be ignored for normal computing purposes. However, for purposes relating to > the method itself (e.g. should we measure BP on both arms to get proper > values? Is this instrument/kind of instrument broken?), which are often data > quality and/or research questions, the protocol can be very useful, and > having it separated will help - it means that no queries to do with the other > parts of the data will be disturbed by the protocol data. > > HISTORY.summary has nothing at all to do with this. We put it in because > Grahame Grieve had identified a use case where there was something like an > image that summarised the data in the time series in some visual way. Here's > the definition from the current release. > > <hjgjjiaj.png> > > In sum, I think the minute we start sliding toward undisciplined data models, > we start heading back toward the non-computable data we have today. Being > able to computably reason about data requires defined structure and solid > theory underlying it. I don't see why we should throw that out the window. If > we say 'everything is a tree', we just get everyone's personal tree structure > preference, and no community agreements on anything. The whole point of a > community in my view is to generate agreements that the wider user base an > use and rely on. > > I would urge people to largely forget aesthetics (i.e. the kind of ridiculous > subjective preferences one hears in XML schema modelling committee meetings), > and concentrate instead on computability and software quality. Failure to do > this got us where we are today... > > - thomas > > > On 26/03/2012 13:33, Ian McNicoll wrote: >> >> 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 > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120327/4e543fd0/attachment.html>
