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

[sjtan]

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

but
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,

http://www.comp.leeds.ac.uk/roger/HiddenMarkovModels/html_dev/main.html

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 encode.py  module,   describes phonetic 
encoding methods starting with SOUNDEX  and ending with double metaphone.
It's like being back at primary school,  "xcchh,  thhh , ssss".