Indeed we had something like this in Release 0.95 of openEHR <http://www.openehr.org/releases/0.95/roadmap.html> - see from the old spec <http://www.openehr.org/releases/0.95/architecture/rm/data_structures_im.pdf>. This HISTORY model worked badly for multi-valued data.
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. 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* > * -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/c0c87d63/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ebgbhgab.png Type: image/png Size: 43856 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/c0c87d63/attachment-0002.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: hjgjjiaj.png Type: image/png Size: 9048 bytes Desc: not available URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20120326/c0c87d63/attachment-0003.png>
