Kevin --
This post is in the spirit of Greg's suggestion to brainstorm alternative approaches.
One alternative is just to ask a local telecom company to provide an end-to-end VPN. I know that you can get decent (or at least acceptable) performance this way. For example, the GT.M development servers are in Middletown, CT. Most of the developers are in Malvern, PA, and access the servers via a network connection through Little Rock, AR.
For another alternative, have you looked at the BCMA backup system (I think that's what it is called) that the VA uses? It is a small VistA system that is located in the wards. For in-patients, it is continuously updated from the main production VistA system by a stream of HL7 messages, so that in the event the main production system goes down, the BCMA backup system has the latest medical records of all in-patients. What is missing in its current incarnation is that any care that is rendered while the main production system is down has paper records which are then entered into the main system when it comes back up.
With the BCMA backup system approach, each clinic would run its own VistA system, but medical records generated there would be streamed to the other clinic - in effect, each clinic would be a BCMA backup system for the other clinic in addition to being a VistA system in its own right. Since the majority of patients are presumably mostly "sticky" in that they will tend to use the most convenient clinic, the volume of paper records to be entered would presumably be small. Or perhaps you just create separate medical records when patients visit the other clinic, and use something like ESIObjects to present clinicians with an integrated patient view.
Now, I am really skating on thin ice. Perhaps someone who knows more about these things than I do can comment on how feasible this is?
-- Bhaskar
Gregory Woodhouse wrote:
Perhaps more to the point, how best to run an application like CPRS in a WAN environment is an interesting problem. Unfortunately, you can't have everything for free, and a simple request/reply paradigm may not be the best way to go over a WAN. There are other alternatives, though. Keep in mind that when the Broker was designed, it was used primarily over a LAN in a single medical center. Instead of just trying to directly port applications to a new environment without really looking at the basic infrastructure, you might be better off thinking about new communications models.
==== Gregory Woodhouse [EMAIL PROTECTED]
------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
