Hi Graham
The summary of the time series can be as structured as you like. No limit ? just archetypes. The fact that the first requirement you expressed was a graphic as part of the report, but it has never been archetyped. Protocol began as there is a lot of data about how information is captured that is of secondary importance. This does not mean it is not important to some key users. The good part about having this set of data is that it can be agreed that by clinicians that they do not want this data ?in their face? when looking at the EHR. This means that there can be a generic display archetype for the different entries that can group this data and make it available through a click, mouse over or whatever. It is pragmatic in a world where we start to share structured data that is not known to a particular system (at least not until a later release.) Cheers, Sam From: openehr-technical-bounces at lists.openehr.org [mailto:[email protected]] On Behalf Of Grahame Grieve Sent: Tuesday, 27 March 2012 5:24 AM To: For openEHR technical discussions Cc: openehr-technical at lists.openehr.org Subject: Re: 13606 revisited - list proposal 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 <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. <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/0c70eb90/attachment-0001.html>
