gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the G


From: Luke Kenneth Casson Leighton
Subject: Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message
Date: Wed, 18 Aug 2010 18:11:58 +0100

On Wed, Aug 18, 2010 at 12:24 AM, Jim Busser <address@hidden> wrote:
> On 2010-08-17, at 2:12 PM, Jim Busser wrote:
>
>> this second scenario especially seems to make the case for logical, 
>> computational, and clinical legitimacy to keep OBR and OBX meaningfully 
>> associated?
>
> I came across a different use case of
>
>        one OBR
>        multiple identical OBX
>
> where a "single test (protocol)" involves the patient bringing into the lab  
> 3 chemically-treated, self-sealing "cards" each of which contains a smudge of 
> the person's feces (yes, that's "bowel movement") applied using a wooden 
> applicator stick... yuk)
>
> Anyway this is referred to as a test for "occult blood" and may be returned as
>
>        OBR-Occult Blood
>
>                OBX1-Occult Blood1
>                OBX2-Occult Blood2
>                OBX3-Occult Blood3
>
> which would seem to make the case that each OBX be imported as its own row 
> (could the subid be stored in GNUmed as a subfield within our test_reult fk?)

  excellent.  a real-world example.  one that's ironically "not shit" :)

 l.

 p.s. message forwarded from someone with experience in HL7 knows the
specs, found ORUR01 (which is what we're seeing as the HL7Message
format) and showed a link to its specification and description, which
explicitly states that OBX _must_ and can only be associated with an
OBR-ORC pair.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]