Hi,

I think I thoroughly agree with Sam on most things, but would like to
add another example:

        Urine?
Acebutolol; 
        arbitrary concentration(IOC Screen; 0 1)
        M = 336,43 g/mol
        Authority: IOC; IFCC/C-LDA; INN 
        NPU01001 
        U?Acebutolol;arb.c.(IOC Screen; 0 1) = ?  

Here is a ordinal scale concentration (either it's there or it's not) of
a substance on the IOC doping list. IOC has a specific procedure (or
rather method) for performing the measurement to guarantee legal
security. This is the level of detail presumably needed by laboratories,
and in this case, athletes.

Regards,
Daniel

On Thu, 2008-04-17 at 05:29 +1000, Sam Heard wrote:
> Hi Daniel
> 
> I would suggest that SNOMED should try and keep the abstract concept
> of something that can be measured at the heart of its ontology. The
> fact that this can be used to define a finding, a target or goal, a
> procedure to measure it, the act of measuring it etc is probably
> better dealt with in the information model ie through post
> coordination.
> 
> Within an archetype for urinalysis the idea of urine bilirubin is a
> non-ambiguous statement from the point of view of context - but
> capturing it in SNOMED is highly problematic as there are lots of
> sorts of dipsticks with different ranges or ordinals etc.
> 
> I know Stan Huff (LOINC), who do use the same code for an order and
> the result (except when they are different - TFTs -> TSH, FT4 etc)
> feels that the general alignment of the concept in the order and the
> result is very important from a safety point of view. Aligning general
> concepts such as Hb is relatively easy, but aligning a code for
> ordering a Hb measurement, the taking of the measurement and the
> result adds enormous overheads.
> 
> We know that IHTSDO are beginning to see alignment with a logical EHR
> as important to simplify this space.
> 
> Cheers, Sam
> 
> Daniel Karlsson wrote: 
> > Dear Everyone,
> > 
> > as said before Snomed (mostly) models "lab properties" as procedures and
> > most other properties as observables. There might however be a change
> > and a "lab observable" hierarchy (whatever a lab observable is?) is
> > under discussion.
> > 
> > Again however, the issue is a bit more tricky as some, although few,
> > properties in lab medicine for comparability reasons needs to be defined
> > up to the exact procedure used when measuring (or observing).
> > 
> > Regards,
> > Daniel
> > 
> > Daniel Karlsson, IHTSDO QA Committee & IFCC/IUPAC C-NPU
> > 
> > On Wed, 2008-04-16 at 12:46 +1000, Andrew Patterson wrote:
> >   
> > > I am making some Snomed bindings for some sample
> > > archetypes but am having some meta-level problems.
> > > 
> > > An example will probably help -
> > > 
> > > Say I want to snomed code the urinalysis archetype. It
> > > lists a large set of potential measurements from a
> > > urine dipstick test - blood, glucose, ketones etc.
> > > Snomed has comprehensive coverage of all of these
> > > categories as 'procedures'
> > > 
> > > 252384001 Urine dipstick for bilirubin (procedure)
> > > 270894005 Urine dipstick for blood (procedure)
> > > 269879003 Urine dipstick for glucose (procedure)
> > > 275714003 Urine dipstick for hemoglobin (procedure)
> > > 271347000 Urine dipstick for ketones (procedure)
> > > 
> > > etc
> > > 
> > > However, part of my brain says that the nodes
> > > within the archetype should really be a finding, as the
> > > actual procedure would perhaps be recorded in a
> > > different archetype and this observation is recording
> > > what was 'found'. However, my initial searching has
> > > found less comprehensive coverage of urianalysis
> > > findings in Snomed - though this may be just that I
> > > haven't searched hard enough.
> > > 
> > > Would it be fundamentally wrong to have a procedure
> > > code in an observation archetype? Are there any
> > > hard and fast rules around this or is it case by case?
> > > 
> > > Thanks
> > > 
> > > Andrew
> > > _______________________________________________
> > > openEHR-clinical mailing list
> > > openEHR-clinical at openehr.org
> > > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
> > >     
> > 
> > _______________________________________________
> > openEHR-clinical mailing list
> > openEHR-clinical at openehr.org
> > http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
> > 
> > 
> >   
> 
> -- 
> 
> Dr Sam Heard
> Chief Executive Officer
> Ocean Informatics
> 
> Director, openEHR Foundation
> Senior Visiting Research Fellow, University College London
> Aus: +61 4 1783 8808
> UK: +44 77 9871 0980
> _______________________________________________
> openEHR-clinical mailing list
> openEHR-clinical at openehr.org
> http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical


Reply via email to