2006/12/18, Ian McNicoll <ian at gpacc.co.uk>: > > Hi Mattias, > > > > I do appreciate these difficulties but if the definition of the binding > changes the binding itself may be obsolete. > If the binding changes so much in the terminology that it may be obsolete in the archetype it would probably lead to a new term that is created in the terminology and the old one is kept... but that doesn't matter in this discussion - just wanted to point it out.
I agree the comment idea is less than satisfactory, it would be better if > the term binding contained the rubric as well as the term code for exactly > the same reasons that the rubric must always accompany the term code in > DV_CODED_TEXT. > I don't know why the DV_CODED_TEXT is designed this way. I have thought about it and the only reason why this is done is probably to get a faster access to the rubric and maybe also when there are no translations for the term in a specific language in order to get a 'default' rubric at all times. Maybe you're right, the definitions could be added as comments, but for proprietary terminology like SNOMED CT this will mean that these kind of archetypes can only be distributed to people that have paid the license. Regards, Mattias > Managing Snomed-CT is going to be a very tricky exercise. Using archetypes > + bindings offers a very powerful way of managing Snomed where semantic > precision is very important e.g. decision support. Having tools that will > let us design and document these bindings will be a powerful way of > persuading those who have yet to understand the value of the archetype > approach. Having the term rubrics available is an important part of > cross-checking that the correct binding has been applied, both for the > original author (where terminology services might well be available) and > when the archetype and bindings are reviewed by a wider clinical audience > (when such services may not be available). > > Regards, > > > > Ian > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061218/854befbb/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
