Hi, The way I like to think about it is that there is a generic archetype for lab-tests as a recurring 'pattern'. Each individual lab test procedure is a code from a general coding system. The way Lab-test are reported (quantitative data, in what units of measurement, precision, normal value ranges, semi quantitative data, in what ordinal scale ,etc, etc) will be 'codes' as well, but this time from the Laboratory Resource Description System.
The 'patterns' will probably be a special type of Archetype that is of the cluster nature. Batteries have Template nature. Gerard On 13, Jun, 2008, at 6:11 , Hugh Leslie wrote: > Hi Daniel > > I was just using that as an example where its not always useful to > code everything. I certainly wasn't trying to say that its not > useful to code anything and the example that you give is where it is > useful to code. I was just pushing back against those that want to > code everything as I believe that we need to code those things that > make sense. > > In terms of battery archetypes, thats another problem because > batterys tend to vary between labs (certainly here in Australia > anyway.) I would expect that it might be templates that solve this > problem with the archetype providing something more generic. Coding > of the analytes would then make sense so that you can compare > different result sets. This could be also solved by producing > archetypes for each analyte and then reusing them for different > batteries. This would then mean that P-ALAT is the same archetype > where ever it is used. Personally, I think the coded solution is > better here as we would have fewer archetypes to manage. > > regards Hugh -- <private> -- Gerard Freriks, MD Huigsloterdijk 378 2158 LR Buitenkaag The Netherlands T: +31 252544896 M: +31 620347088 E: gfrer at luna.nl Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20080613/37cb8174/attachment.html>
