On 12/31/05, Gary Monger <[EMAIL PROTECTED]> wrote:
You make a strong argument. It does seem to be a big job, and I have decided not to wade into it right now.
Regarding solving our network, the real solution would be to purchase a dedicated T line. But that is something like $500-$700 a month, I have been told. We would like to switch from DSL to Cable, but the cable company keeps stalling. I think they are trying to strong-arm the hospital (which we are adjacent to) into purchasing cable service for all the hospital rooms (which isn't going to happen).
I agree.
At first glance, this kind of does sound like what I would want, i.e. separated databases caching changes until the update can be propigated. But maybe I am wrong. Even so, I don't want to change to Cache'
I appreciate your feedback.
Kevin
It sounds like the problem is best solved by fixing your network issue. I
doubt the expense of upgrading your network will exceed the expense of a
homebrewed synchronization solution for VistA.
As the preceding posts indicate, VistA does not lend itself to such
synchronization. It's a big job, your time has to be worth something. It
would also require substantial custom code that would be at risk anytime you
load patches. You would then have to ensure that patches did not overwrite
your changes.
You make a strong argument. It does seem to be a big job, and I have decided not to wade into it right now.
Regarding solving our network, the real solution would be to purchase a dedicated T line. But that is something like $500-$700 a month, I have been told. We would like to switch from DSL to Cable, but the cable company keeps stalling. I think they are trying to strong-arm the hospital (which we are adjacent to) into purchasing cable service for all the hospital rooms (which isn't going to happen).
Absent the network issue, it does not appear you have a need for two VistA
databases. If there were such a business need, not solved by using multiple
divisions on one database, and patients would regularly visit both sites,
you might have a case for synchronization.
If there were several such sites, you might have a case for an MPI. MPI
provides a means to synch identity, it does not synch clinical data. It's a
separate system, and would introduce a new set of issues, but still not
solve the basic concern of allowing the clinicians fast access to the
relevant data.
I agree.
ECP is Enterprise Cache Protocol. If you have multiple cache servers, its
how they talk to each other. You could potentially allow users at both
sites to connect to a local system that would appear as a single system to
all. I strongly suspect it requires a good network. The advantage is that
the remote system is caching the data pages, which should work pretty well
for typical user operations. However, if you only need to occasionally dump
all of a patient's data, it may not be the best choice.
At first glance, this kind of does sound like what I would want, i.e. separated databases caching changes until the update can be propigated. But maybe I am wrong. Even so, I don't want to change to Cache'
Kevin
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] ] On Behalf Of chuck5566
Sent: Wednesday, December 28, 2005 8:35 PM
To: [email protected]
Subject: Re: [Hardhats-members] Two site database synchronization
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
