Sorry Grahame forgot to add, I probably have some sympathy for your view on protocol but I wasn't quite sure what you meant by "we face the situation where the structuring data is "protocol"" - can you give a concrete example.
It is quite clear to me that many of the attributes and structures introduced by the ENTRY sub-classes are necessary, and that the ontological background of the 'clinical investigator model' is about as good as it gets, but that in some circumstances the structural requirements and ontology can be orthogonal, which leads to the kind of lengthy debate and philosophical discussion that can bedevil other clinical modelling formalisms. Some of that is unavoidable, as you said on your blog, clinical information is complex. We cannot avoid that complexity, just hide it or move it elsewhere. I think openEHR has made a pretty good job of hiding the complexity, or at least presenting it to the correct audience, but I think we can do better. In particular, I think we need to try to reduce the burden on new entrants i.e make it easier to get started and feel confident that any models devloped are not 'wrong' from the outset but can gradually be made more sophisticated over time, as experience grows. I take Sam's point about he value of 'protocol'. It is a very valuable way of organising complex data within an archetype but can be a matter of fine judgement and debate amongst clinicians and is important to get right since we are making a structural commitment which is going to break queries if we decide to change our mind later. It can also cause problems in OBSERVATION, since occasionally 'protocol' items really merit being in the 'state' structure and vice versa, from a temporal perspective. It also has only 'soft' semantic value, a kind of guideline rather than anything which is going to be queried directly. It is valuable but wonder we can deliver this more flexibly by annotating the item, rather than a structural attribute, in much the same way as we are proposing to deal with ITEM_STRUCTURE. This overlaps somewhat with the discussion on ADMIN_ENTRY and EVALUATION and generic ENTRY - I think we need to retain the ontology but I don't think this needs to be absolutely tied to the structural definitions. At the moment we force archetype authors to make a very early commitment to a specific class and the class structure and ontological classification are intextricably bound. In most cases this is not an issue, the decision is easy. In other cases, the decision is very hard but important , and lengthy discussion unavoidable. What concerns me are the cases where the decision is somewhat arbitrary and debatable but actually inconsequential, in terms of future querying. I think this can be real barrier to uptake since it switches off the many who just want to get a job done, worst still becomes a bone of contention for those who favour a different ontologcal view of the world. If ontology and structure were less entwined, we might minimise this problem. Just to be clear, we do need the more complex structures provided by the ENTRY sub-classes and we do no need the 'clinical investigator' ontology, but we do have to recognise that there is resistance to this complexity and an intellectual burden for new entrants. I think we might be able to reduce the resistance and intellectual burden without losing the value. Ian On 27 March 2012 09:12, Ian McNicoll <Ian.McNicoll at oceaninformatics.com>wrote: > Hi Grahame, > > I am struggling a little to understand your concern about the Summary > attribute (other than that is is not supported in the tools!). The current > definition "optional summary data expressing e.g. text > or image which summarises entire history." seems to me to meet your needs > perfectly. I am obviously misunderstanding your requirement or we have > different interpretations of the definition. How would you like to broaden > the definition? > > Apologies if this is old ground for some people, but I think the > discussion is useful to a wider audience, in the context of a bit of > blue-sky thinking for openEHR 2.0 and 13606 alignment. > > Ian > > > On 27 March 2012 03:30, Grahame Grieve <grahame at healthintersections.com.au > > wrote: > >> hi Sam >> >> > 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. >> >> except that the definition is "optional summary data expressing e.g. text >> or image which summarises entire history." I don't think this definition >> is >> sufficiently broad, and I always get unaccountably uncomfortable when >> people ignore the restrictions imposed by definitions. >> >> > 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.) >> >> except that we face the situation where the structuring data is >> "protocol", >> the details are very much "in the face" kind of stuff, and therefore this >> coupling of "paradigm" and "not in the face" breaks down. >> >> Grahame >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at 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 > > -- 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 *Primary Health Info 23 ? 25th April in Warwick ? are you coming?<http://www.primaryhealthinfo.org/> * Clinical Modelling Consultant, Ocean Informatics, UK Director 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/20120327/ba801d7f/attachment-0001.html>
