[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] Lab import (data) matching
From: |
James Busser |
Subject: |
[Gnumed-devel] Lab import (data) matching |
Date: |
Sun, 03 Feb 2008 13:47:28 -0800 |
Before we can develop something configurable in which GNUmed
installations can define their rules for matching, we would have to
figure out the kinds of requirements.
In the case of having "unique" outgoing reference numbers that could
be returned to GNUmed and assist a "match", I think such numbers may
not always be enough, by themselves, for two reasons.
The first is that there is a possibility of human transcription error
when such numbers are not always scanned. For example, even though in
Germany it may be that the lab provides the stickers whose numbers
are to be entered in GNUmed but in other countries it could be
possible in GNUmed for the praxis to generate its own incremental
unique request_ids (in clin.lab_request) and if this gets printed on
paper, the workers at lab reception would need to input the number.
The second is because there may not be a 1:1 correspondence between
the tests requested and the results that are returned. In Canada, I
provide a patient with (normally) a single piece of paper on which I
have for example written:
- hematology profile
- lipid profile
- urine screen
where each of the above really represents a "compound" request which
will generate multiple component results. Conveniently the GNUmed
table clin.lab_request seems to already recognize that any request as
being able to include multiple items.
Also the results will not all be available at the same time, and
there will be a workflow to consider how partial results get handled
(for example the lab provides confirmation that a test has been
requested, but this test may not be done as frequently as the others
and so that result may not be available until a future pick-up.
Back to the matching, the potential match fields could be
request_id (GNUmed's internal ID for the request of interest, may be
unique)
lab_request_id (ID this request had internally at the lab, may or
may not be unique)
fk_test_org (which in Canada could be different lab companies and
different branches)
... therefore in Canada we can not know if any fk_test_org we would
put in will be correct
... also the above will have no value when we were *copied* results
on a patient
patient surname
patient given names
patient date of birth
patient sex/gender
patient account number (health insurance or other health number)
patient account type / identifier
patient external_id (if we store the lab's id for this patient)
patient other demographics (address, phone, postal)
requestor of the test (where the person is a member of the praxis)
copy-to doctor for the test (where the person is a member of the
praxis)
The biggest problem to matching is usually variants of the first or
middle names or exchanges between them e.g.
Smith, Ann Marie
Smith, Annie M
Smith, Marie
Smith, A Mary
can be different forms of the same person.
Re: [Gnumed-devel] Lab import (data) matching, Elizabeth Dodd, 2008/02/04