Hi Hugh and Gerard, I very much agree that snomed coding should only be done where it adds value. Since archetypes provide meaning themselves not everything has to be coded (as opposed to HL7 that relies more on external codes). Although for export to non-openEHR formats (or data-mining on openEHR *and* non-EHR data) it could still be useful. But since finding suitable codes can be very tough, such "gimmick" coding will probably rarely happen in the first instance.
Using codes to reduce the number of archetypes is a very valuable use case. Having a generic archetype as a recording pattern (e.g. lab archetype) and using codes to specify the actual analyte makes sense. As mentioned before templates should be used to aggregate these archetypes in a specific testing 'battery'. Looking at the openEHR archetype repository, there is a generic lab archetype and several specialiced ones based on it. However, it seems to me that the specialisations were done mainly to create "battery" type lab results structures (e.g. laboratory-liver_function) I think keeping the lab archetype to one analyte and aggregating them in a template would be cleaner and better from a query perspective. Specialisations of the generic lab archetype should only be used to add a field that is missing for an unkonventinal lab test. What do you think? Again, I would like to point you to the terminology use case section in the openEHR wiki: http://www.openehr.org/wiki/display/healthmod/Archetypes+and+Terminology#ArchetypesandTerminology-Usecasesforterminologyreferencesinarchetypes Lets fill this use case list in a *collaborative* manner. It is better to have our thoughts in a permanent spot (wiki) than only in a mailing list thread where they get burried and forgotten after a while. No hesitation, add/rearrange etc as you please ... everything is versioned so nothing gets lost! Hugh, could you add the "fewer archetypes" use case please. Cheers, Thilo On Fri, Jun 13, 2008 at 10:53 AM, Gerard Freriks <gfrer at luna.nl> wrote: > 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 > > > > > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > >
