Re: [Gnumed-devel] HL7 Importing Lab Results/Contacts

[Karsten Hilbert]

On Wed, Jul 06, 2011 at 08:05:48AM -0700, Jim Busser wrote:

> I think it is important that we correctly understand (agree on) the 
> implications of "any particular solution" whose success depends on
> 
> - what the sending lab supplies by way of data and
> - the particular implementation of the HL7 via which it is being provided
> 
> The consequences:
> 
> 1. if you import data whose supplier and HL7 implementation *conform* to the 
> expectations, relative happiness should ensue

Absolutely. And, of course, it is everyone's right to
foster/fund/promote a solution tending to his/her particular
problem. No question about that.

If that solution comes sufficiently specific (so the
boundary conditions of its use are well defined), not
unnecessarily duplicative of existing functionality, and
sufficiently conformant with design principles, then it
stands good chances to get included with GNUmed. Chances
rise if the solution - despite being tailor-made - adds good
chunks of generic functionality.

> End-result: I would much rather accept the limitations of a text stream, 
> which I could at least route into "documents" of description
>
>       "brainless lab page report"

:-)

What you describe is IMO an entirely sane point of view.

> however, thanks for pointing out the need to build, into the HL7 importer 
> code, a check for whether GNUmed recognizes the
> 
>       MSH 003 Sending Application ID
>       MSH 004 Sending Facility 
> 
> as "approved" to be processed by the particular importer code.

I didn't think to phrase it that way but that's pretty much
what I meant. I'm not sure Luke has fully appreciated this
truth from the trenches. This is also the very reason why
the apparently much-hated Mirth exists.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346