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
