Re: Security of Patient Data

[Wayne Wilson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tim Cook wrote:
|
| If this is truewhat method(s) are the GP's using to prevent exposing
| private patient data to modification and/or interception by third
| parties?
|
What I find more interesting is the data, or more precisely, the lack of
it, that supports technology to prevent modification and/or interception
by third parties.
We take it as a fundamental assumption that because it's technologically
doable (the compromise of data), it must be prevented.  Some countries
even write regulations and laws about it.
But there are many things in this world that have adverse consequences
as a result of technology.  What made this one reach such an exalted
state of concern?
Actually, it's the latter question that really interests me, because
when I started to investigate what the magnitude of the problem was, I
discovered the lack of evidence.
There is certainly the fundamental risk equation which balances costs of
implementation against potential costs of compromise.  One argument goes
that if the implementation cost is extremely low, we need not calculate
the potential compromise cost.  I think that is true for SSL on the Web,
at least when it comes to the cost of labor for implementation, which is
extremely low. The impact on transaction costs is another thing, but
once again, that is rarely calculated...
My current favorite theory to explain why we elevate some consequences
into standard practice, in the absence of evidence, is a combination of
the following social phenomena mixed with low labor costs of implementation:
Fear of the 'bad guy', i.e. the bogeyman will get ya.
Technological imperative, i.e. more technology is better then less
technology.
What I ultimately would like to understand, and use this security case
as nothing more than an example (i.e., it's not special in and of
itself), is how those two social phenomena are driving the informational
transformation of medicine.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA0DssY+HG7UEwVGERAmk6AJwNrJNsaBWBl2fzqEzGwX1PYaLYGQCfXXbB
D2cg5FUOeA4KIJQ2IjlzQ7k=
=ZsuS
-END PGP SIGNATURE-

UC Berkeley: Linux Adoption in the Public Sector: An Economic Analysis

[J. Antas]

Very interesting reading.
Hal Varian and Carl Shapiro, two economics professors from the 
University of California at Berkeley, have written a research paper 
describing some of the economic issues surrounding open source and open 
standards software and its adoption by the public sector.

Seen on: 
http://linuxtoday.com/news_story.php3?ltsn=2004-06-11-031-26-NW-MR-PB

Or, download the (small) report file from:
http://www.sims.berkeley.edu/~hal/Papers/2004/linux-adoption-in-the-public-sector.pdf
J. Antas

RE: CoreFLS program at VA Hospital

[Kantor, Gary]

 Dear Mr Nohlgren,

Although I initiated the thread on the story about the new enterprise
resource application for the Veterans Health Administration, I am not
sufficiently knowledgeable about large health care systems
and how they handle their billing, inventory control and asset
management to comment as you request. 

The discussion on this list - the OpenHealth List - concerns open source
software for health care systems, both large and small. I will forward your
request to the membership of that list so perhaps someone will respond
directly to you. 

Large information system projects of this nature are prone to failure, for
many reasons. The reason I introduced the story into the list was because
the VA, the largest health system in the United States, has had enormous
success with its clinical information systems, which were created by staff
of the VA, and are in the public domain thanks to the Freedom of Information
Act. In this instance, the VA appears to have taken a different tack with
software development, with disastrous results.

Gary Kantor MD
Case Western Reserve University
University Hospials of Cleveland

-Original Message-
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: 6/15/2004 4:36 PM
Subject: CoreFLS program at VA Hospital


Mr. Kantor: 

I'm a reporter for the St. Petersburg Times. My colleague, Paul de la
Garaza, and I have written several stories about CoreFLS and the VA. We
are hearing, in some quarters, that they are now eight months into their
rollout and some employees still have trouble making it work. This is
not gospel, maybe much  of it is griping from people who are
institutionally resistant to change. But given a cost approaching a
half-billion dollars, plus the disruption that occured down here with
just one hospital, we are spending considerable effort to sort out
whether these problems are typical startup ills or inherent and likely
to continue when the project expands to 160 hospitals. Among other
things, it appears to run on a WAN with people working live on one main
server in Austin. Employees report slow response times. What's going to
happen when 160 hospitals go on-line? 

I am looking for people knowledgeable about large health care systems
and how they handle their billing, inventory control and asset
management. Certainly the VA is enormous, but I imagine this sort of
software challenge has been faced by others to some extent. We need to
know what questions we should be asking. 

I stumbled across your thread on the internet on what I take to be a
site frequented by people interested in health care and software
development. 

Please give me a call, when you get a chance. 

Thanks, 
Steve Nohlgren 
1-800-333-7505 x 8442 

\ge 



The enclosed information is STRICTLY CONFIDENTIAL and is intended for the use of the 
addressee only. University Hospitals Health System and its affiliates disclaim any 
responsibility for unauthorized disclosure of this information to anyone other than 
the addressee. 
 
Federal and Ohio law protect patient medical information disclosed in this email, 
including psychiatric disorders, (HIV) test results, AIDs-related conditions, alcohol, 
and/or drug dependence or abuse. Federal regulation (42 CFR Part 2) and Ohio Revised 
Code section 5122.31 and 3701.243 prohibit disclosure of this information without the 
specific written consent of the person to whom it pertains, or as otherwise permitted 
by law.