[241] in Commercialization & Privatization of the Internet
Re: Other Researchers
daemon@ATHENA.MIT.EDU (Sean McLinden)
Thu Feb 28 16:03:23 1991
Date: Thu, 28 Feb 91 15:26:22 -0500
From: sean@dsl.pitt.edu (Sean McLinden)
To: craig@sics.se, dan@sci.ccny.cuny.edu, jqj@duff.uoregon.edu
Cc: com-priv@psi.com
re: education about Internet (and Internet strategies) versus others
Dan Schlitt <dan@sci.ccny.cuny.edu> suggests that education is needed
as well as increased visibility of the Internet in areas in which it
is not, typically, found (BITNET communities, for example).
In part I agree with this and, in part, I am remined of Marshall Rose's
admonition "Users are interested in services not protocols!"
In the early 80's I was responsible for the University of Pittsburgh's
first ARPANET connection, a 9600 baud link to a fuzzball at CMU. In the
mid 80's it was upgraded to a 56Kb link because in a University community
of over 8,000 faculty I was finally able to find someone else who had
a need for ARPA connectivity (a researcher doing work for ONR). This
entire connection was supported via soft money from two research grants.
It was not until the late 80's that campus administrators saw a reason
for such a connection. Even then, we were faced with a campus that had
only two sites (the two that I mentioned earlier), running TCP/IP.
In 1989 I moved from the University to the University Medical Center.
This is a 1600 patient care institution which supports 8 Vaxen, plus
a number of workstations. Until recently, the Vaxen only ran DECNet.
It is still the case that in spite of having a network of over 100
CPU's, we (Research Division) still need to submit a formal request to
have TCP/IP services installed on new machines (in spite of the fact
that in another part of the building the clinical applications group
is discussing the installation of 80 X terminals in clinical ares
although none of them know what TCP/IP is!)
The point is, I guess, that for a large segment of the community, ignorance
of the Internet does not seem to be a problem; BITNET is just fine,
perhaps because it does exactly what they want it to do. Unless there is
a need for the service, it is very hard for many sites to justify it.
Education might help, but you'd be educating the potential users who,
in many cases, are not the ones who will (ultimately) make the decision
to pay the cost of connection to this service.
There are two other efforts which suggest an alterate (or, perhaps,
an additional) approach to promoting this service.
The first is GOSIP. In theory, the Federal government is in a position
to specify that requests for telecommunications services for Government
contracts and grants be compliant with certainly Federally recognized
standards when such standards exist. I say "in theory" because in spite
of having this in place, the government issues billions of dollars in
grants and contracts each year which will employ telecommunication
standards and which will not require use of those which are Federally
mandated.
As an example, the Health Care Finance Administration (HCFA) and the
Agency for Health Care Policy and Research (AHCPR) are in the process
of contracting for the development of strategies for the collection,
storage, and communication of patient medical record data and yet in
none of these contracts are GOSIP or other standards required and in
a few cases, competing technology is being developed. If we are going
to begin education, we should begin it at the Federal level and we
should establish some standards where it is practical for standards
to exist. This is not a case of need; the need is demonstrably there.
It is a case of education, and recognition of the value of such a substrate
as the network to the task of collecting and managing data such as that
presented by HCFA and AHCPR.
The second example is that of EXPRES which demonstrated that developing
technology is a lot easier than making it work in real social situations.
As pointed out by another author in an earlier message, the difficulty is
not in convincing us information scientists that we need such a system.
After all, we're all here. The difficulty lies in demonstrating to the
other communities that we have something to offer them that will improve
the quality of their lives. In a sense, we tackle the problem backwards
and tackle the wrong problems.
Look at three examples: Athena, Andrew, and EXPRES. Each of these projects
had lofty goals. Each of these resulted in the development of some very
significant software packages and, equally as interesting, social processes.
But none of them really accomplished what they set out to do. In part, I
suspect, because they tackled problems that were not problems that needed to
be "solved" with this technology. Electronic classrooms and electronic
libraries on college campuses seems like a great idea until you consider
why it is that people go to college. It isn't to sit in front of a VDT!
So who are the communities that are likely to need such technologies as
NREN?
Well, much of the scientific community (with the exception of NIH which
has caught up to within 10 years of current techology), much of the
military, the academic community (for netnews, e-mail, and FTP). In essence,
all the people who currently use the Internet. Who is left?
The business community? Well, yes, but business traditionally avoid
"Open Systems" and information sharing chosing, instead, to have one
way gateways, invisible nodes, or to not have a direct connection at
all. Information science companies are the worst for this. It was only
recently that DEC had a reasonable gateway to the Internet (although
WRL has been on for a long time). IBM, similarly, has low profile
presence as well as HP which prides itself on it's networking sophistication.
I mean the Interstate highway example only goes so far since you can
watch a truck go by but it takes some effort to open it up and look
inside. Fear of the lack of security and, perhaps, inappropriate utility
would preclude a substantial business input to NREN.
But there is another (alluded to, earlier) and untapped market: the
public health sector. The Federal government is, after all, responsible
for the care of some 30 million Americans (through HCFA) and another 20
million through the VA, Indian Health, and Maternal and Child Care
programs. They monitor the care of these people using *photocopied*
medical charts submitted to regional PROs who operate under contract
to HCFA. Each year they review about 16% of all of these admissions
limited only by the ability to store, communicate, and evaluate
information. They have a very poor system of data collections which
limits their ability to monitor health care and hospital trends. They
are developing better systems for classifying patient data, but
have no good systems for communicating this or for linking it to
hospitals. Blue Cross, the largest private insurer, collects data by
requesting magtapes from the hospitals with coded data. Sometimes a
cutting edge FAX is used.
There are thousands of health care institutions in the United States
with a pressing need for daily communication with insurers, the Federal
government, laboratories, and other hospitals, and no one is servicing
this need.
Two years ago I suggested to William Wolffe, author of the White Paper
on the National Collaboratory, that the U.S. patient care area would be
a perfect testing ground for the development of high speed, secure,
reliable, and distributed multimedia data communications and was told
"we (NSF) can't touch medicine." Seems to me its time to rethink that
idea. Why?
1. The Federal government is charged, by law, with the responsibility
to administer the public health.
2. Next to the cost of health care, itself, the second largest cost to
this process is monitoring.
3. Increasingly, the data being monitored are accessible in electronic
form as coded data elements or free texts while more and more hospitals and
clinics are employing computer systems for patient recordkeeping.
4. Increasingly, other agencies such as insurance companies are
also requesting access to electronic patient data for monitoring.
It seems to me like a classic case of Sutton's Law. But while you can
lead a horse to water, you can't always convince him that he's thirsty.
Sean McLinden
Decision Systems Laboratory
University of Pittsburgh
