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 10:12 PM, Jim Busser <address@hidden> wrote:
> On 2010-08-17, at 9:06 AM, Luke Kenneth Casson Leighton wrote:
>
>> i'm trying to make it clear - perhaps this helps: any HL7-formatted
>> "observational report" which contains OBXs that do not have a
>> preceding OBR is rejected at the HL7 parsing (syntax) level.
>
> I erred in providing only a part of the message (lest I be required to 
> include all the way up to the MSH)

 understood - i was just being fussy.

> however the example from which I cut and pasted *did* have an OBR, and all 
> OBX (the one with no subid, and the ones that contained subid1 and those that 
> contained subid 2) all related back to the same OBR (see below *****)

 euuurgh.

 ok - could you tell me: this message, was it an "update" message?
i.e. had at any time, for messages with subid "2" had there been any
prior message (with the same OBR 003 lab id) where there was a subid
of "1"?

 regardless, it kinda says that non-empty subids have to be tolerated.  *sigh*.

>
> These were provided as a single block.
>
> The subids provide a solution for two scenarios. For each is provided a 
> scenario and my (maybe flawed) thoughts as to some options:
>
> 1) when a lab supplies multiple (and therefore non-unique) OBX having the 
> same LOINC inside a single message... the subid here preserves granularity 
> among these:
>
> ORC|RE||03000032-PATHC-0|||||||||22333^MEDIC^IAN^TEST
> OBR|5||03000032-PATHC-0|PATHC^Pathologist 
> Comments|R|20030827091101|20030827091101|||||||20030827091101||22333^MEDIC^IAN^TEST||||||20030901105929|||F||^^^^^R|87878^TEST^JANE~22333^MEDIC^IAN^TEST
> OBX|1|TX|X10011^Pathologist Comments|1|Result 1||||||F|||20030901105401
> OBX|2|TX|X10011^Pathologist Comments|2|Result 2||||||F|||20030901105401
> OBX|3|TX|X10011^Pathologist Comments|3|Result 3||||||F|||20030901105401
>
> ... the above is kind of understandable as to not need to be (clinically) 
> separated into separate rows if GNUmed would choose instead to coalesce them 
> into a single row,  because these are all comments about a single OBR 
> specimen (such as a biopsy... a single piece of tissue)

 if that action is chosen, how do you a) distinguish comments from
actual "real" measurements b) deal with an update message on subid "2"
for example?  you can't, can you?  thus, the information has to be
preserved: subids have to be part of the indexing.

> 2) microbiology results -- the method provides a way for an initial OBX 
> (which does not have a subid) to keep associated with it the data contained 
> inside the remaining OBX which both follow and which *do* contain a subid, so 
> GNUmed could choose to coalesce all of these into one row (for the urine 
> result) despite that this urine result contains -- if you like -- two 
> subresults.
>
> this second scenario especially seems to make the case for logical, 
> computational, and clinical legitimacy to keep OBR and OBX meaningfully 
> associated?

 not in my mind it doesn't.  the discussion above is more of a case
for logical, computational and clinical legitimacy for adding a
test_unit_sub_id to clin.lab_result.

l.