....that's what I was hinting at too :-)
Kevin Toppenberg wrote:
I think it would be a straight-forward as creating the functionality and distributing it with our version of WorldVistA. Put a layer of security in such that both parties have to agree to the transfer, and suddenly any two users of the system can transfer data.
Kevin
--- Joseph Dal Molin <[EMAIL PROTECTED]> wrote:
Miscellaneous ramblings......and thinking out loud
Perhaps we have a window of opportunity and some
significant strategic opportunity outside the VA since there are not many
VistA installs yet and the data standardization issue is not as
daunting (or is it). Outside of the VA environment, assuming we have one
standard version of VistA.... wouldn't the data standardization problem
be eliminated?
Could there be one common approach via on demand
and/or batch peer to peer record exchange using a shared MPI for a) data
collection and aggregation eg. to support quality improvement,
research etc. b) remote back up and recovery?
Joseph
Cameron Schlehuber wrote:
I was indeed referring to the approach BCMA
represents ... and you are quite
right that significant work remains to extend that
kind of
central-distributed functionality. In addition to
the Herculean work
remaining for the development of the HDR (most of
which will be in the data
standardization efforts), the Clinical Data
Service capabilities must be
further fleshed out and refined as we gain
experience in actually using it.
A key principle is that not all patients are
replicated to every distributed
system, but ONLY those patients of interest during
a particular time-frame.
When the patient is scheduled (or just shows up)
after years of absence from
a given facility, that patient's whole set of
records are gathered to the
local system and all completed transactions to the
clinical record (could
also be the administrative record as well) are
committed to both the local
system as well as the central system (and any
other system that is also
currently "interested" in the patient's record.)
After some preset time of
no reference (say, 30 days) that patient's records
are simply purged from
the local system but are permanent on the central
repositories (note that
the VA won't have the only repository!)
-----Original Message----- From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Kevin
Toppenberg Sent: Friday, May 13, 2005 7:42 AM To: [email protected] Subject: RE: [Hardhats-members] Re: Slow CPRS
performance over VPN
Never mind, based on other comments, I don't think that BMCA is a viable option without significant extension.
Kevin
--- Kevin Toppenberg <[EMAIL PROTECTED]> wrote:
Cameron,
Bhaskar made several suggestions. Which one are
you
referring to?
I am most attracted to the BCMA system. But I suspect that there will be steep learning curve, and I
don't
want to invest time in it if I am headed in a fruitless direction.
Kevin
--- Cameron Schlehuber <[EMAIL PROTECTED]> wrote:
I think that Donald nailed the issue. CPRS
indeed
keeps its messages short, but there may be quite a few of them. It works rather well over a 28K modem (without a VPN or router in the way), but will indeed be slow with a VPN over a WAN that has other traffic to compete with ... even though the overall bandwidth remains high.
Bhaskar's suggestion is indeed a reasonable
approach
and is one that I have been pushing for quite some time. Of note is
that
Northrop Grumman IT has evolved a similar approach to field units that
can
do health care delivery and recording in the temporary absence of connectivity to centrally reposited information. It's also a model that I hope will end up being part of HealtheVet-VistA.
-----Original Message----- From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of K.S. Bhaskar Sent: Thursday, May 12, 2005 6:17 AM To: [email protected] Subject: Re: [Hardhats-members] Re: Slow CPRS performance over VPN
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
=== message truncated ===
Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html
------------------------------------------------------- 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
.
------------------------------------------------------- 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
