Here is my thinking: VA may at somepoint come out with a system that does what I want. But it is not here now, and I don't know when HDR will be done. So I will probably need to create my own system if I really need it.
An outline of my approach for creating my own system would be: 1. Set up functionality for exporting patient records (in part or in whole) in XML. 2. Set up an HL7 interface that utilizes the XML-formatted data. (I a bit fuzzy on this here, are HL7 and XML mutually incompatible?) 3. Set up a query system that asks the remote system what data it is missing, and only pass over new or changed data. I would then have a server at each office for real-time access. Then, at a slower rate, the updates could be propigated to the other offices. >From an architectural point of view, how does this sound? Kevin --- Cameron Schlehuber <[EMAIL PROTECTED]> 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 > > > 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 > === message truncated === Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.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
