Re: [Gnumed-devel] Matching was Re: Mirth (2 of 3): HL7 import for the GNUmed project - test source message

[Luke Kenneth Casson Leighton]

On Tue, Aug 17, 2010 at 3:53 PM, Jim Busser <address@hidden> wrote:
> On 2010-08-17, at 1:25 AM, Karsten Hilbert wrote:
>
>>> the only reason i overloaded encounters was because there was no
>>> other way to preserve the OBR-OBX hierarchy.  place something in the
>>> database that i can use and i'll use that instead.
>>
>> I do realize that and we will put something in the database. What you did
>> there was fine for the time being.
>>
>> Now we need to find out what the OBX-OBR link IS in clinicians terms.
>
> So we are maybe determining whether an operational requirement (namely, to be 
> able to logically relate incoming results, to any results that are already 
> existing) has a clinical meaning, or whether it needs to live somewhere to 
> the side of the clinical data, in order to not confuse the clinical data with 
> a non-clinical meaning?
>
> Let us see...
>
> - the OBX is a single instance, of any one test result, of a certain test 
> type, transmitted inside exactly one OBR
> - the OBX does contain a provision for (it contains a field) subid where 
> multiple "lines" of a result (each of which carry the same LOINC) need to be 
> provided, for example when the LOINC is "Pathologist's comments" or when the 
> LOINC is "Urine culture" there may arise more than one comment or more than 
> one bacteria/organism within the result... if I recall correctly there was a 
> feeling that this subid might a technical device --I am just wildly 
> hypothesizing here --- e.g. to better support the inflow of data and that in 
> place of GNUmed supporting the subid within the GNUmed result table, such 
> data could just be concatenated (maybe with line feeds) in a single pooled 
> text field. But this was not the question, though the context is maybe still 
> helpful...

here is an example which demonstrates that 2nd level of hierarchy:

ORC|RE||03000032-PATHC-0|||||||||12345^DR_SURN^DR_FIRST^
OBR|5||03000032-PATHC-0|PATHC^Pathologist
Comments|R|20030827091101|20070827091101|||||||20070827091101||
12345^DR_SURN^DR_FIRST^||||||20070901105929|||F||^^^^^R|
87878^DOE^JANE~12345^DR_SURN^DR_FIRST^
OBX|1|TX|X10011^Pathologist Comments|1|Result 1||||||F|||20070901105402
OBX|2|TX|X10011^Pathologist Comments|2|Result 2||||||F|||20070901105402
OBX|3|TX|X10011^Pathologist Comments|3|Result 3||||||F|||20070901105402

 in hierarchical terms this can be turned into the following:

 ORC - 03000032-PATHC-0
    |
   +- OBX X10011 Pathologist Comments
         |
         +- Result 1
         +- Result 2
         +- Result 3

 so in this example, i've had to represent that 2nd level of hierarchy
by overloading the test_unit table to create test units with a
different name (by appending OBX sub-id as a string in brackets to the
test_unit nme field) but keeping the LOINC code the same of course.

... it would be good to not have to do this, by having a
clin.test_result.unit_sub_id field.

l.