Harold: it is also my understanding that this is a clear weakness of VISTA in its current configuration (the lack of granularity to access). Solving this problem would appear to invlove wrapping each data field with some sort of security level identifiers. Is there a model for that process? David ----- Original Message ----- From: "Harold A. Mackey" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 09, 2002 4:47 AM Subject: RE: Medsphere
> Folks > I have spoken to a hardhat or two regarding Vista and I was told that > any port of this software would be a very large undertaking. I was > wondering if in the process of creating a usable open source model some > consideration is given to creating a method of controlling access to > patient information that envisions the eventuality of such a system > becoming widely used within the medical community. Currently access to > emr information is given by granting a user/passsword to the whole data > store with admonitions to mind your own business, but we all know what > happens to usernames and passwords in a community setting such as a > hospital. Looking to a future where the emr is comprised of many > interconnected datastores, or a centralized one for perhaps a state or > large city, this method of granting access does not seem to scale well. > Consider the scenario where pathology labs, radiologists, etc. are all > tied to a single store, or directly access the referring physicians > datastore to pass information. The local regional hospital also is tied > to the store or has access to it's referring physician's data. There > must be a method of allowing granular access to these stores. I assume > that the referring physician will be the ultimate grantor of rights to > information. This physician submits a request for lab results and along > with the request a ticket is given to submit the results back to the > store. The consulting physician may or may not be allowed to view the > patient record. > Another scenario would be the emergency room of the local hospital > requesting immediate access to a patient record in the referring MD's > store, where a ticket is passed because of tacit approval by the > patient. Rights to that information are then given by the examining > physician to his fellow and the nurse coordinator, etc. Somehow all of > this has to be controlled. > Finally, isn't it time to allow the patient to have some input into this > record? > > Thanks > > Harold A Mackey > Digestive Disease Center > Medical University of South Carolina > 95 Jonathan Lucas Street > Suite 210 CSB > Charleston, South Carolina 29403 > ph 843-792-4858 > fx 843-792-4184 > > > > > > -----Original Message----- > From: david derauf [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, August 08, 2023 6:07 PM > To: [EMAIL PROTECTED] > Subject: Re: Medsphere > > > Interesting to see VISTA emerge from under the rocks as a flower that > appears willing if not quite ready to bloom on this thread. Is this an > example of the 100th monkey principle at work? For those of us still on > the periphery, looking in on all of this, any advice on how best to > prepare ourselves to get involved? David Derauf > > ----- Original Message ----- > From: "Andrew Ho" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, August 06, 2002 1:40 PM > Subject: Re: Medsphere > > > > ok, I managed to dig up a little more info about medsphere (via > > Google): > > > > The MedSphere Wiki (very informative): > > This seems to be the *real* MedSphere site. > > > > http://dev.medsphere.com/wiki/wiki.cgi?HomePage > > > > For project direction/status, see the two medsphere 1 notes: > > (This one has a good overview of current Vista) > > http://dev.medsphere.com/wiki/wiki.cgi?Documentation_8-1-02_Thursday > > > > (This one provides a sketch of development goals) > > http://dev.medsphere.com/wiki/wiki.cgi?Documentation_8-3-02_Saturday > > > > The MedSphere team: > > > > David Whitten: [EMAIL PROTECTED] > > Project Task Leader, focused on design and overview of project George > > Welch: [EMAIL PROTECTED] Developer, focused on modularization > > > and parameterization of Core VistA Steve Shreeve: > > [EMAIL PROTECTED] Developer, focused on CPRS, RPC Broker, > > and collaboration website Chris Richardson: > > [EMAIL PROTECTED] Developer, focused on releases and > > statistical analysis Rick Marshall: [EMAIL PROTECTED] > > Developer, focused on infrastructure > > Brian Lord: [EMAIL PROTECTED] > > Developer, responsibilities include Mumps, C, Delphi, and testing > > Dee Knapp: [EMAIL PROTECTED] > > Documentor, focused on documentation and providing information for the > > collaboration website > > Clyde Asato: [EMAIL PROTECTED] > > Developer, focused on quality assurance > > > > Very impressive! > > > > Andrew > > --- > > Andrew P. Ho, M.D. > > OIO: Open Infrastructure for Outcomes > > www.TxOutcome.Org (Hosting OIO Library #1 and OSHCA Mirror #1) > > >
