Re: [Gnumed-devel] proposal for HL7 v2.3 to gnumed parsing

[Ian Haywood]

Karsten Hilbert wrote:

> What if several matches occur ?
>
> Please also consider using test_result_unmatched and propose
> improvements thereupon if necessary.
I agree.
Using a dummy patient is seriously bad IMHO, reason is, unmatched results
are going to be *common* over here. Even Horst's "super-smart" matching 
algorithm
can only match 90% unaided, so we need a special interface
for manual matching.

P.S. Horst, please post said algorithm!

> > parsing Hits OBR,
> > if the message has ordering_provider field, which has a form
> > (id, title, firstname, lastname) , then an attempt is made
> > to match in v_staff
> > also attempt to match to each ~ separated provider 
> > in results_copies_to field, if it exists.
IMHO the parser should still work if OBR is absent.
(Remember most HL7 implementations don't "play fair", they ignore the standard 
when and as they please,
and users will always blame gnumed when we can't parse them!
> > If no match, then ? match to staff who has corresponding current_user name?
Yes.
> > and test_results can be created which can be linked into lab_requests.
>
> yes
The reality of the AU situation is this isn't going to work, as we don't
(yet) have electronic ordering, it would require the pathologist's
clerk to copy our reference number on the paper request into the computer.
AFAIK, most wouldn't bother. (Nevertheless, we should support printing such
numbers on request slips)
I expect most real messages will have a blank or nonsense value here.
(Probably even with electronic requests)
IOW, our system needs to cope, and be usable, where most results can't
be linked to a request.
> > What needs to be done on the backend may be more precise fields in lab_request to 
> > store loinc_code, and loinc_name ?
Create an entry in test_type if one doesn't exist.
test_type.code <- LOINC code (the first subfield of OBX-2)
test_type.name <- test name (the second subfield of OBX-2)
test_type.coding_system <- "LOINC"
test_type.fk_test_org -> IMHO less significant in AU. Syan, consider making 
this always NULL in the first instance.
This is because AFAICT results are either all free text (so any form of coding 
is pointless) or LOINC
test_type.conversion_unit -> ????

Karsten, I note this last field is not null. However in AU 90% of our results 
are free text
(even when in principle they should be numeric) so "units" unfortunately loses 
all meaning.
what should we put here?

Ian