Thanks Grahame, "Summarisation"
I think I probably have a somewhat more liberal interpretaion of 'summarisation' , which would include analysis or interpretation of the data, to include 'tissue/lab/x-ray diagnosis' but short of clinical diagnosis. I found the recent JAMIA paper on the"AORTIS model" extremely helpful in clarifying my thinking on this. "Our model identifies five distinct stages of clinical summarization: (1) Aggregation, (2) Organization, (3) Reduction and/or Transformation, (4) Interpretation and (5) Synthesis http://www.sciencedirect.com/science/article/pii/S1532046411000591 In my view everything below synthesis belongs in an Observation, since it relates to the observation or test itself and not to the patient as a whole. This get a little hazier in anatomical pathology, particularly haematological disorders, but even then there is a fairly clear distinction between a tissue diagnosis, which is partof a lab report and an actual diagnosis. I think it is clear that we need some structural attribute within OBSERVATION to represent clinical information that applies to the whole event series. Querying will otherwise be pretty difficult. I think we also recognise that we need some way of simplifying OBSERVATION for the 80% of single event uses and for integration without sacrificing the less common but significant need for multiple event handling. (I think this + associated tooling) would resolve most of the issues you had in the NEHTA context. "One issue I have is that the event series imposes the same data at each point," - can you give an example? and by "repeating observations is protocol" do you mean situations where the method changes at each Event e.g. First blood pressure taken with cuff, second with a machine? If so, I probably agree. In most cases the ontology and structure coincide but there are cases where something that ontologically is protocol needs to be in an event and vice-versa. I don't want to lose protocol. I think there is value in making the distinction as part of the authoring process, if only as a way of making an archetype easier to view, and as Sam suggests to underpin a generic view, but I don't think we need to tie it to structure. Ian On 27 March 2012 10:41, Grahame Grieve <grahame at healthintersections.com.au>wrote: > hi Ian > > It meets perfectly the requirements I was aware of at the time, but now I > have > a more perfect (ahh, less imperfect) knowledge. If I have a series of > observations, > I may provide some interpretation of them, that becomes the "observation". > This occurs with several diagnostic tests. But these cases > don't "summarise the entire history", in that they analyse the data. > Perhaps I am splitting hairs, but isn't that what definitions are for? I'd > like it relaxed a little. > > And tooling support, too, of course ;-) (though I suppose I could add > that myself) > > Generally, in the NEHTA context, we've struggled with the openEHR RM here. > Partly it's tooling (AE and CKM) - it doesn't support the things we want > to do. > We've ended up pretending that the event series doesn't exist in the > observation RM > for the purposes of the archetype, both (partly) in how the design was > done, > and (completely) in how we convert the archetype to a DCM. Partly that was > a > pragmatic decision to do with tooling limitations, but it's not > obvious to me that > it would've played out differently if the tooling wasn't limited. > > One issue I have is that the event series imposes the same data at each > point, > which is not necessarily the case. And also, (back to protocol) > repeating observations > is protocol? (how they were each done), and this summary thing - is it > critical > to display, or just an adjunct? Better just to model the content in > data and be sure... > > Grahame > > > On Tue, Mar 27, 2012 at 7:12 PM, 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 > > > > > > _______________________________________________ > > openEHR-technical mailing list > > openEHR-technical at lists.openehr.org > > > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > > > -- > ----- > http://www.healthintersections.com.au / > grahame at healthintersections.com.au / +61 411 867 065 > > _______________________________________________ > 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 *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/2ec4527b/attachment-0001.html>
