Hi Sheng, A few of my comments below...
Ian Dr Ian McNicoll office / fax +44(0)141 560 4657 mobile +44 (0)775 209 7859 skype ianmcnicoll ian.mcnicoll at oceaninformatics.com ian at mcmi.co.uk Clinical Analyst Ocean Informatics openEHR Archetype Editorial Group Member BCS Primary Health Care SG Group www.phcsg.org / BCS Health Scotland On 11 March 2010 16:32, Sheng,Yu <sheng.yu at dit.ie> wrote: > Dear Thomas, Mikael and Michael > > Thanks for the useful comments which I will try to digest and > incorporate into my study. > > I note that two of my original questions remain unanswered > > - Are there any mature templates - linked to existing archetypes which > I could use to extract bindings? These templates could be in any format. > > IAN: Not just yet!! I am about to a do a little work on defining some 'histological diagnosis' termsets for a series of structured histopathological reports that we have developed for the RCPA. I would be hasppy to share these with you when they are developed. I would expect other s to emerge as partof some National and vendor programs but we do not expect all that many to be applicable at international level. I think we are now in a position to start adding/revising a number of per-node bindings to archetypes within CKM, as a degree of consensus is emerging through the CDA/CCD Snomed bindings in the common archetypes such plulse, BP etc. > - In your experience, where are bindings generally positioned in an > archetype or template? Is this ONLY decided by terminologists or will > there also be style guide / principles to (for instance) constrain the > possible position of bindings? > > IAN: It depends on the style of term-binding. Single-node 'term-bindings' will probably be mostly within archetypes, whilst 'constraint/query/termset bindings' will tend to be at template level and may be quite use-case specific (though perhaps based on broader parents). Inevitably this is not absolute but our experience with the CKM international archetypes is that we have not yet defined any meaningful constraint queries, other than the highly simplistic e.g Is_a_diagnosis in the Problem-diagnosis archetype. Although we don't experienced terminological input to CKM just yet, I donlt personally think that this will change the balance between archetype and template bindings. The issue of where anfd how to apply individual node term-bindings within archetypes, will be influenced by terminologist support , though I would expect that to be coupled with a good understanding of how the info. model and terminology should best interact. The excellent paper refererred to by Stef,gives me considerable hope that a more nuanced view of the value and application of terminologies is becoming evident. In addition, I have the following question > > I read the wiki page authored by Thomas that discusses the equivalent > of Archetypes and Terminology. I am interested in the concept of > deriving a terminological artefact that gives an idea of the content of > Archetypes. (In my work we are calling this a terminological "shadow". > I would like to know - In your opinion - do the bindings in Archetypes > represent some clues to the coverage of clinical content? > IAN : I would be interested in hearing more about this shadow idea. I have had some thoughts about archetypes and templates being able to represent themselves as being equivalent to one or more post-coordinated terms, rather in the way that 'interfaces' are used in Java or .Net to allow classes to offer the functionality and attributes of other classes, in the absence of true multiple inheritance support. So the OBSERVATION.blood_pressure archetype might 'emit' interface bindings for both an Observable and Procedure based post-coordinated SCT terms, and make these available for reporting purposes or querying. Just an idea, but we do have to hide the complexity of any SCT post-coordination in some fashion. Regards, Ian Regards > Sheng > > This message has been scanned for content and viruses by the DIT > Information Services E-Mail Scanning Service, and is believed to be clean. > http://www.dit.ie > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20100311/a958d805/attachment.html>
