[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fwd: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 201
Fwd: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010
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
> 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
>> -- Jim
>> Gnumed-devel mailing list
> 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
> 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
> 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
> 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
> As I don't use commercial software, and my program is old and didn't have
> 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.
- Fwd: [Gnumed-devel] Open Source Health Informatics, London, 30th Sep 2010,
Jim Busser <=