[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] address@hidden: Announcing the Portal]

From: sjtan
Subject: Re: [Gnumed-devel] address@hidden: Announcing the Portal]
Date: Sat, 04 Sep 2004 07:36:08 +1000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616

Didn't find any substantial record exchange methodology blaring out from a quick look,

I looked at their little critique on febrl ; not a bad summary. The normalized demographic gnumed schema makes it more difficult to incorrectly enter addresses though, IMO.

deduplication using febrl or similiar batch processing might require gnumed to have a cron scheduled task, and widget for viewing
accumulated candidate deduplications that haven't been committed.

febrl might have a role in import of multi-clinic -attending patients' records (i.e. linkage) as well.

on the other hand, manual opportunistic merging of found duplicated records during patient search is an old favorite, and requires no
background processing time.

BTW , there's a great tutorial on HMM on a leeds' uni website,

that helps with the standardization piece of the febrl puzzle ( the analogy is that as dry, soggy, or damp seaweed is the observable state that changes and dictates the most probable hidden state sequence of cloudy, sunny, rainy weather , so the sequence of an address word tokens is the sequence of observable states that has a maximally probable sequence of hidden address component types ( wayfare no, wayfare name, locality name, postcode etc) , that can
be used to standardize the address.

the febrl source itself , the module, describes phonetic encoding methods starting with SOUNDEX and ending with double metaphone.
It's like being back at primary school,  "xcchh,  thhh , ssss".

reply via email to

[Prev in Thread] Current Thread [Next in Thread]