[Top][All Lists]

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

Fwd: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 201

From: Jim Busser
Subject: Fwd: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010
Date: Mon, 16 Aug 2010 07:48:49 -0700

Begin forwarded message:

> From: richard terry <address@hidden>
> Date: August 15, 2010 6:15:10 PM PDT
> To: Jim Busser <address@hidden>
> Subject: Re: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 
> 2010
> On Monday 16 August 2010 06:29:02 Jim Busser wrote:
>> On 2010-08-15, at 12:21 PM, Luke Kenneth Casson Leighton wrote:
>>> ... remind me... why is gnumed adding HL7 data importing, or any data
>>> importing at all, if the suppliers can't be bothered to put themselves
>>> in order?
>> IMO it remains useful to have some (mostly) agreed to definition of how
>> messages are structured...
>> The *content* of these messages, and whether and how such messages are
>> created and made available, is distinct and important but the above part
>> (the HL7) remains arguably useful!
>> It is better to have a starting point, than to have no starting point at
>> all.
>> -- Jim
>> _______________________________________________
>> Gnumed-devel mailing list 
>> address@hidden
> Jim could you post this to the list.
> Just for the interested, the situation in Australia may be a little different 
> where any program without hl7 downloading wouldn't be looked at.
> All GP's here (think) that they are downloading hl7 reliably and regularly.
> All our pathology comes in hl7, and though there is variable compliance to 
> the 
> standard in use here  (the major teaching hospital at least in our region 
> being the main offender) the system seems to run well.
> Notice the word 'think' above.
> I've done a bit of programming in hl7 over the last 12/12 and actually 
> presented a paper at a conference here (small - just for IT interested 
> doctors), in which I documented the existing problems with hl7 sent to 
> practices. Multiple problems, aside from the obvious ones like mis-spelt 
> names, there can be variable adherence to standards even like putting the 
> names in the right segment/subsegment. Sometimes test names have been 
> missing, 
> or loinc missing. 
> I wouldn't be a bit surprised if a proportion of HL7 message end up in a 
> 'black hole', rather than the users computers. There is no closing of the 
> loop 
> done properly between the message sender/receiver.
> Also on a programatic level, programming in hl7 becomes 'exception' 
> programming -having to take into account the errors coming from  particular 
> vendor, in order to be able to parse the files properly. It is said, and this 
> may not be correct as it is only anectodal, that the major software vendor of 
> GP software has a different parser written for each software company.
> Having said ll that, GP's find it reliable and useful. The hl7 is downloaded 
> regularly, eg every 10 minutes onto ones local machine, and ends up in the 
> inbox.
> As I don't use commercial software, and my program is old and didn't have 
> this 
> in it - I personally still rely on a web-interface to the pathology companies 
> server in Sydney that I use, but I'm the 'odd man out'.
> Liz could comment to the list how she finds it.
> Specialists letters are a different matter:
> Major messaging companies now send specialists letters via hl7 (eg Medical 
> Objects - you can  check their web  site if interested).  The only problem is 
> not being able to receive images. The hl7 received in this format I'd say is 
> 100% reliable.
> I looked at Mirth and gave it a miss personally.
> Its important that gnuMed have the ability to handle HL7 I would have thought.
> Regards
> Richard

-- Jim

reply via email to

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