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

[Karsten Hilbert]

On Fri, May 13, 2005 at 06:18:49PM +1000, Ian Haywood wrote:

> >>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.
Surely so. As per "be liberal in what you accept and strict in
what you emit".

> >>and test_results can be created which can be linked into lab_requests.
> The reality of the AU situation is this isn't going to work,
Notice the "can" in the above sentence.

> as we don't (yet) have electronic ordering,
Neither do we. All we do is enter the request numbers into our
EMR systems. The rest of the request is on plain old paper with
barcode stickers of the request numbers (mind you, the
e-request specs are there but no one uses them). Only that we
get back our results electronically complete with the request
number - which is barcode scanned in the lab.

> it would require the pathologist's
> clerk to copy our reference number on the paper request into the computer.
This is done by barcode over here: In the office we put a
sticker with a barcoded request number on the request slip
which is then scanned by the lab and thus attached to the
sample (which is barcoded with the same number) and the
results.

> AFAIK, most wouldn't bother. (Nevertheless, we should support printing such
> numbers on request slips)
Printing isn't used anywhere in Germany AFAICT. But, hey, it's
useful.

> I expect most real messages will have a blank or nonsense value here.
> (Probably even with electronic requests)
Very likely for AU it seems.

> IOW, our system needs to cope, and be usable, where most results can't
> be linked to a request.
Absolutely.

> >>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.
Exactly. That's what our LDT importer does.

> 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"
preferably with a uniquely versioned coding_system string ...

> test_type.fk_test_org -> IMHO less significant in AU. Syan, consider making 
> this always NULL in the first instance.
agree, it's just there for when the data is readily available

> This is because AFAICT results are either all free text (so any form of 
> coding is pointless) or LOINC
> test_type.conversion_unit -> ????

comment on column test_type.conversion_unit is
    'the basic unit for this test type, preferably SI,
    used for comparing results delivered in differing
    units, this does not relate to what unit the test
    provider delivers results in but rather the unit
    we think those results need to be converted to in
    order to be comparable to OTHER results';

If a new test is coming in I would suggest using the unit
supplied with it for that field - it may not be the best
choice mathematically but surely works.

> 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?
I see. Good point. I hadn't considered this properly I
suppose.

Upon further thought I'd say let's make that nullable. But not
"default null" so programmers have to think about it.

I added a conditional constraint to test_result which enforces
units on numeric results...

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346