Kevin,
Apologies if I mentioned this before, but have you looked over the
docs for VistA's Master Patient Index (MPI)?
(http://www.va.gov/vdl/Infrastructure.asp?appID=16)
The MPI is similar to what it looks like you are trying to accomplish
- it might you give ideas/insight. I believe the MPI deals only with
patient demographics, but it does synchronization of databases and
does use it's own patient identifier, they call an ICN. A new
patient is given a local ICN, used until the site updates the MPI
when the site is given a national ICN for the patient(s).
On Dec 28, 2005, at 9:04 AM, Kevin Toppenberg wrote:
I have written about about synchronizing two databases on and off
over the last 6 months or so. I have some new thoughts that I
would like comment on.
First, some context. We have two offices linked by a slow vpn with
high latency times (high round-trip time for pings) which makes
using CPRS at the remote site a chore. The idea of synchronization
was to allow the user to add the data to the local database, but
then to have the changes propigated to the remote database.
The fundamental problem, as I see it, it a problem of record
numbers, or IEN. For example if the two databases are identical at
the beginning, and Dr. X's note it put into database A, and Dr. Y's
note is put into database B, then these could potentially have the
same (conflicting) IEN in the file. Then, with synchronization,
one note would clobber the other.
But it seems that this problem should be easy to overcome. Each
database could simply hold a translation table of IEN's. For
example, imaging the following synchronization process. I'll use
the terms dbA and dbB to refer to database's A &B
1. dbA says to dbB, lets synchronize
2. dbB says, I have a record in file 8925, IEN=1234
3. dbA uses translation lookup table for 8925 and finds no record
of IEN=1234, so says, send it to me.
4. dbB sends the record, and dbA adds it to file 8925, with a
different IEN, 6789
5. dbA puts in lookup table: dbB-1234=dbA-6789
6. Furthermore, as dbA is adding record 1234, it notes that the
record contains pointers to other files, so it looks up each
reference and translates the IEN to the local IEN number. And if
the record is missing, it requests it from the server (repeating
this process).
Does this process seem reasonable?
The fundamental principle here is that the database entries are the
final repository for all of VistA's information. This could
possibly be incorrect. For example, some packages are designed so
that data can only put into the database through their code. This
is achieved, I believe, through secretly defined variables and
input screens etc. Also, I have run into problems in the past
with adding records, when field Y fails unless field X has already
been added. (I think I can overcome this problem with repeated
calls to the filing process, because each failed attempt seems to
be partly successful, and puts in a little bit more into the record)
Any thoughts?
Kevin
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Hardhats-members mailing list
Hardhats-members@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/hardhats-members
