Hi Tom, now I am very clear on how openEHR looks at this whole thing and agree :)
Having said that, I'd be very keen to hear about especially GUI design and runtime data entry and validation aspects from implementers. In this case the thing is not simply parsing the archetype structure and terms and building functionality, but now an openEHR based application will need some means to access the terminology, get the terms, get relationships and possibly do some processing. I will be looking forward to seeing the CTS2 specification. In a similar vein I remember the discussions about semantic references or links at openEHR previously. I don't remember how this ended but I was reminded recently that in fact EN13606 has Semantic Links defined in its reference model which can be used within and across archetypes. This looks to me to cause serious divergence between openEHR and CEN (and possibly ISO). At any rate I think it would be quite useful to have a simple tool with which simple terminology content can be created and persisted in XML. Many thanks and cheers, -koray Thomas Beale wrote: > > Hi Koray, > > Koray Atalag wrote: >> Hi Tom, thanks for the comments. I see your point (and others' who >> mailed me directly). >> >> However I am not totally satisfied with the assumption that we can >> separate descriptions of information vs. real world in a perfectly >> clear way. I mean the organisation and hierarchy plus the at/ac terms >> given in an archetype for a clinical model still gives a lot of clues >> about the real world aspects. Am I still missing something here? > > In some kinds of medical information, the shape of the information > certainly looks similar to the ontological description of the same > thing - GI investigations being a good example. Nevertheless, the > ontological representation contains the 'truth' - i.e. the statements > expressing medicine's idea of the various structures, and importantly, > their classifications. The archetypes can't do either of these things > - they can't be taken for being a true model of the gut, for example, > nor can they adequately express classificatory relationships. So the > ontology will always be richer in these areas. The archetypes on the > other hand will be richer in observational detail - size, shape, > character of lumps, narrowings, pockets, lesions, etc. > >> >> So now I'd like to withdraw my previous suggestion and present another: >> >> What about having the means to be able to define a relationship type >> and the relationship between individual terms (with at/ac codes) >> given in the ontology section. I am talking about really simple >> relationships but also aware that this is clearly a duplication of >> terminology functionality; however this would greatly ease most of >> the typical implementations of openEHR - I mean without going into >> complexity and potential performance problems when working with a >> terminology service. > > I don't think we should be saying this. If terminology is 'difficult' > we need to make it easier. Just because of some technical difficulties > (of which I am not aware) we should not break the philosophical basis > of a modelling paradigm. As soon as we add some facilities to > partially model terminology, people will step into that world in > archetypes, and ask for more; then we will be in trouble, because we > will be replicating what is in Snomed, ICDx, ICPC and all the rest. > >> I can also see relatively easy GUI generation if the relationships >> behaviour is straightforward. >> Of course for SNOMED and possibly other decent terminologies >> terminology service is a must. > > not just Snomed; various countries have numerous very small > terminologies, one could really only call them vocabularies. These > benefit hugely from being available in a terminology service, because > it provides: > > * an authoratative source > * a capability for update > * a query facility > * some services will provide a capability for subsetting > > I would recommend people look at the CTS2 specification when > published. I think in openEHR we should not shy away from 'proper' > solutions - there is no lasting value in over-simplified approaches. > > - thomas beale > > > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4286 (20090728) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > ------------------------------------------------------------------------ > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 4286 (20090728) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > -- Koray Atalag, MD, Ph.D Clinton Bedogni Research Fellow The University of Auckland, Department of Computer Science, Private Bag 92019, Auckland 1142, New Zealand Tel: +64 (9) 373 7599 ext. 87199 Fax: +64 (9) 308 2377 Email: koray at cs.auckland.ac.nz __________ Information from ESET NOD32 Antivirus, version of virus signature database 4286 (20090728) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20090729/35c7456b/attachment.html>
