[Top][All Lists]

[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: Sat, 14 Aug 2010 13:24:19 +0100

On Fri, Aug 13, 2010 at 11:58 PM, Jim Busser <address@hidden> wrote:
> 2) if the lab refused to fix it, you could persuade your praxis 
> administrator, in GNUmed, to create alias
>        Smith, John STUPID LAB ALIAS

 that works!  i like it.  esp. the word "stupid" :)


 let's just hope that, after the first incorrect response, they don't
do something silly like lose and/or change the name.  heck, if they
do, thinking about it, you can always brow-beat them into putting in
the correct details, delete the lab request with the incorrect patient
(as previously discussed, actually, now that i think about it).

>>> <snip>
>> ah.. are you saying that you would, given that the proposed
>> fk_lab_request would preserve the OBR-OBX hierarchy (in
>> clin.test_result + clin.lab_request), that you would want to then
>> begin changing the encounter with which the lab_request and/or
>> test_result was associated?  perhaps move the test_results to
>> somewhere more appropriate?
> yes


>> if so, that kinda breaks what's been discussed already about keeping
>> clin.lab_requests + clin.test_results associated with "automated lab
>> import" encounter/episode types!
> it only breaks what might have been the permanence of the association. I 
> should point out that, all along, GNUmed has figured on the encounter as 
> serving an able-to-be-altered grouping function so I apologize that this 
> maybe led to competing expectations.
> While personally I might be happy with associating results with a clinical 
> encounter only in the case where results had been manually-inputted, and 
> instead using the "episode" as the grouping parameter, I see no need for a 
> "victor" in this argumentation if the encounter dependency can in fact be 
> removed. :-)


 i think it's going to be essential to have that fk_lab_request in


reply via email to

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