This offlist thread seems to have nearly, but maybe not fully, identified how to complete the name matching of an incoming result "patient name" string against the multiple names per person supported in GNUmed.
Is Luke correct when he identifies something needed for lab test import, but which cPatientSearcher_SQL() maybe does not handle?
**************************************************************************
On 2010-08-04, at 6:29 AM, Luke Kenneth Casson Leighton wrote:
ok - i've added an external id search, which will pass in the issuer
and id_type _if_ specified on the function, but otherwise if None will
search just on the external_id itself.
On 2010-08-04, at 6:38 AM, Karsten Hilbert wrote:
This will provide false positives.
On 2010-08-04, at 6:44 AM, Luke Kenneth Casson Leighton wrote:
... which can be mitigated by implicitly knowing the issuer+type (as
in previous message).
and also remember that it matches by name or DOB. On 2010-08-04, at 6:38 AM, Karsten Hilbert wrote:
Most of this is already (or should be) covered in business/gmPerson.py.
On 2010-08-04, at 6:44 AM, Luke Kenneth Casson Leighton wrote:
unfortunately i cannot use that code, had to cut/paste it and adapt
it. reason: if the HL7 message has an external id, you want to be
searching through the external ids table by external id and then
narrow down by name _or_ date-of-birth.
the code in gmPerson.py assumes that you have a cPerson object already.
On 2010-08-05, at 2:41 AM, Karsten Hilbert wrote:
It doesn't. It can also search on sort-of-structured
arbitrary search terms (but may still not suit your needs).
On 2010-08-05, at 3:01 AM, Luke Kenneth Casson Leighton wrote:
i couldn't work that out, and would have to create those search terms
anyway, so it was simpler as a first version to just do the search
terms inside gmPG7.py (5 lines of code after creating the search
terms) and then create cPerson objects plural in a for-loop (3 lines
On 2010-08-05, at 3:49 AM, Karsten Hilbert wrote:
Like, prefix with "#" for a number or with * for a DOB ?
That's all there in gmPatientSearcher_SQL, mostly in
_generate_simple_query() but anyway.
It most certainly already searches for external IDs (albeit
On 2010-08-05, at 3:01 AM, Luke Kenneth Casson Leighton wrote:
yes. that's why i had to do it separately. the existing code forces
the addition of a person pk to the query
On 2010-08-05, at 3:49 AM, Karsten Hilbert wrote:
Where ?
On 2010-08-05, at 5:21 AM, Luke Kenneth Casson Leighton wrote:
as the very first two lines:
class cPerson....
....
def get_external_ids(self, id_type=None, issuer=None, context=None):
where_parts = ['pk_identity = %(pat)s']
args = {'pat': self.ID}
the non-optional addition of self.ID (aliased as a python property to
return pk_identity) is the reason why this function cannot be used.
and, because cPerson looks after "one person", it makes sense to have
this non-optional addition of self.ID to the query.
On 2010-08-05, at 6:12 AM, Karsten Hilbert wrote:
i'm not sure if you understand what it is that i need to do. i need
to get a *list* of potential identities (by external id) *not* "one
single person". then, once i have a list of potential identities, go
through them one by one (creating a cPerson object on each) and _then_
assess their dob and name.
On 2010-08-05, at 6:12 AM, Karsten Hilbert wrote:
Of course. That's exactly why gmPerson.py::cPatientSearch_SQL
exists which is what I've been saying for a few mails.
On 2010-08-05, at 6:37 AM, Luke Kenneth Casson Leighton wrote:
yehh, i know - but ahh, i know what happened: i tried it, and found
that there's no function _generate_queries - there is only a function
called _generate_queries_de.
if parse_search_term:
...
...
queries = self._generate_queries(search_term)
so... yes, after looking closely at the function
_generate_simple_queries(), it turns out to have some
pattern-recognition for external ids, by placing "#" in front, but
possibly matching against gnumed id as well, but still not checking
the external id type or issuer, i would _still_, even after using
cPatientSearch_SQL, _still_ have to create a list of patients, and
_still_ have to call patient.get_external_ids().
so it doesn't actually save much in the way of code, doesn't fit with
the very specific rules/heuristics needed for lab importing, and has a
bug (missing function) which i'd forgotten about and forgot to mention
until now. sorry :)
On 2010-08-05, at 6:57 AM, Karsten Hilbert wrote:
Which ? I'd like to fix that :-)
On 2010-08-05, at 7:49 AM, Luke Kenneth Casson Leighton wrote:
there is no function _generate_queries. there is only _generate_queries_de
:)
On 2010-08-05, at 7:56 AM, Karsten Hilbert wrote:
¹if and when someone writes any other self._generate_queries_$LOCALE
Oh, but there is:
class cPatientSearcher_SQL:
"""UI independant i18n aware patient searcher."""
def __init__(self):
self._generate_queries = self._generate_queries_de
This is intended to eventually¹ be configurable per locale.
Karsten
On 2010-08-05, at 8:03 AM, Luke Kenneth Casson Leighton wrote:
bizarre. i wonder why it didn't work? oh... i wonder if i did
cPatientSearcher_SQL. ... instead of cPatientSearcher_SQL(). ...
oh well. can't use it anyway, but no bug, at least.
-- Jim
|