> The system at present is performing mappings on pre-modeled archetypes
> depriving it the luxury of having access to the author.
This is what I meant by the 'split' case - a split between the people/group
constructing the archetype, and the people doing the binding (in this
Sam writing the archetype and you guys doing the terminology stuff). It
doesn't lessen your points about the difficulties of doing the terminology
mapping - I just wanted to clarify that the plan in the 'best case' is
that there wouldn't be so much of a split (i.e. you'd be in communication
with the people writing the archetype, or it would all be done within one
tool by the same author)
> I agree that this URL feature sounds a bit complex. Not having complete
> knowledge of the Ocean methodology and objective makes it rather difficult
> to comment though. However, 'is_a' trees are only part of the solution to
> the binding/mapping process. There are a few archetypes that have 'is_a'
> terms and can be dealt with in a less complex way i.e. without the use of
> URL's.
Other than actually enumerating the term codes in the ADL file, what other
mechanism is there other than URLs?
> Though am not sure whether the Ocean team had something else in mind
> when using URLs.
The URL system is not inherently bad - it solves the problem in a
relatively clean way that allows lots of room for future developments
in terminologies without constraining the solutions. I just worry that
with complex terminologies like snomed being used more often
it may be useful to have an inbetween solution i.e.
simplest)
list of codes typed in '123123', '3242342', '123123'
* moderate *)
simple langauge like "limit depth 5 (is_a('102323','arm fracture'))"
complex)
http://www.termserver.com/saved_query?realm=uk&concept_root=1231231
Andrew
_______________________________________________
openEHR-technical mailing list
openEHR-technical at openehr.org
http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
