-- <private> -- Gerard Freriks, arts Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands
T: +31 252 544896 M: +31 654 792800 On 21-aug-2005, at 14:38, Thomas Beale wrote: > Gerard Freriks wrote: > > well, in general that's the idea. But the question at hand is about > coding in the reference model itself, i.e. for the structural (hard- > wired) attributes that have coded values - in other words, things > which we have specifically chosen not to archetype. > There isn't much mileage in archetyping the code-set of > ENTRY.language, for example - we don't want to open such a basic > thing up to variation in archetypes. Instead we want it controlled > inside the reference model and openEHR vocabularies. The original > question of CR-150 was whether we should bypass even this > flexibility and simply specify that such attributes are of type > String (or maybe an enumerated type) and hard code them into the > model. In my view, this is problematic in all sorts of ways - the > main one is that each implementor will do this in a different, > probably in compatible way. I agree. > > >> - select a coding system and produce a 'ancestor archetype' that >> uses codes from a specific coding system. >> > > This topic of 'ancestor archetypes' is a different issue. I am not > yet sure what they are - are they any different from a normal > specialisation parent archetype? Certain archetype fragments will be needed. They are the prototypic ones. The ones I'm calling 'ancestor archetypes' are the standardised starting points we use to derive archetypes of. They act as the start of families of archetypes. The ones dealing with observations, the ones expressing measurements, etc. > > >> - over time a new 'ancestor-archetype' will be produced using a >> new version of the specific coding system or a new coding system >> altogether. >> > > well, this already happens for the code-sets fo language and > country etc, using the openEHR vocabulary approach for them - that > is, we have openEHR_language and openEHR_country vocabularies which > wrap the ISO code-sets; this allows us to change what they wrap, > add extra codes and so on. > Good. Am I correct to see the wrapper as the 'ancestor archetype' and the variants as archetypes each constraining the 'ancestor'. > >> - the question now is how to handle interoperability. The answer >> is the use for an 'archetype ontology'. One we miss at this moment. >> > > in general, that's true, but it wouldn't make any difference for > the basic vocabularies of language and territory. Several parts of the archetype ontology will we extremely simple. Other parts will not. > > - thomas > > - > If you have any questions about using this list, > please send a message to d.lloyd at openehr.org > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20050821/1ab42fd6/attachment.html>
