msc@saber.UUCP (Mark Callow) (12/23/85)
> I'm developing a patient medical record system for a community-based hospital > built around Unix workstations.... > ....The configuration requires a minimum of 30 nodes; the > relational DBMS must support a least 12 different views of the medical > database, which will have 68+ relations. This may seem very silly. It did to me when I was told but... A close friend of mine who does consulting work in the areas of communications, networking and UNIX was once working with a hospital. They ruled out use of ethernet because it is expected to have failures (i.e. collisions) and they were afraid that some clever lawyers might label this as negligence. Lawyer to jury: "this institution installed a system expected to have periodic failures which would delay critical patient information. Yet they tell you they care about their patients". Yes I know it's ridiculous but that was their concern. You can bet the lawyer would carefully pick a technically naive jury. Anyway the point is, before proceeding with your system you might want to check up with the hospital administration and legal people. I can refer you to my friend for more information if you like. -- From the TARDIS of Mark Callow msc@saber.uucp, sun!saber!msc@decwrl.dec.com ...{ihnp4,sun}!saber!msc "Boards are long and hard and made of wood"
eric@osiris.UUCP (Eric Bergan) (12/26/85)
> > I'm developing a patient medical record system for a community-based hospital > > built around Unix workstations.... > > ....The configuration requires a minimum of 30 nodes; the > > relational DBMS must support a least 12 different views of the medical > > database, which will have 68+ relations. (I missed this first article, could some kind soul please mail me a copy? We are doing very similar things, and it would be nice to see what else is being done. We already have a patient medical record system up and running, supporting a database of 2.1 million patients. Thanks.) > This may seem very silly. It did to me when I was told but... A close > friend of mine who does consulting work in the areas of communications, > networking and UNIX was once working with a hospital. They ruled out > use of ethernet because it is expected to have failures (i.e. > collisions) and they were afraid that some clever lawyers might label > this as negligence. Lawyer to jury: "this institution installed a > system expected to have periodic failures which would delay critical > patient information. Yet they tell you they care about their > patients". Yes I know it's ridiculous but that was their concern. > You can bet the lawyer would carefully pick a technically naive jury. > > Anyway the point is, before proceeding with your system you might > want to check up with the hospital administration and legal people. > I can refer you to my friend for more information if you like. We (Johns Hopkins Hospital) have built and are building several clinical information systems which are distributed across several machines (supermini and workstation) connected using Ethernet. These projects will even include order entry for tests, etc on patients. But there has been no problem from the legal department about the use of ethernet. All systems can break. Negligence is failing to provide a reasonable (electronic or otherwise) backup for when the system does break. Now what we have been talking with the legal department about is what consitutes an "electronic" signature. Given an environment of unattended terminals, and users' typical inclinations to write down passwords, just what is necessary and sufficient proof of identity when ordering surgery? -- eric ...!seismo!umcp-cs!aplvax!osiris!eric
mwg@petrus.UUCP (Mark Garrett) (12/27/85)
++ > > This may seem very silly. It did to me when I was told but... A close > > friend of mine who does consulting work in the areas of communications, > > networking and UNIX was once working with a hospital. They ruled out > > use of ethernet because it is expected to have failures (i.e. > > collisions) and they were afraid that some clever lawyers might label > > this as negligence. Lawyer to jury: "this institution installed a > > system expected to have periodic failures which would delay critical > > patient information. Yet they tell you they care about their > > patients". Yes I know it's ridiculous but that was their concern. > > You can bet the lawyer would carefully pick a technically naive jury. > But there has been > no problem from the legal department about the use of ethernet. All systems > can break. Negligence is failing to provide a reasonable (electronic or > otherwise) backup for when the system does break. Somehow I would expect that even a lawyer [:-)] could explain the reliability of ethernet in layman's terms. It is incorrect to consider a collision to be a failure in any sense. The transport and network layer protocols must insure that colliding messages are re-sent accurately. The CSMA/CD (ethernet protocol) scheme can be compared to trying to place a call on the phone. Just because you sometimes get a busy signal doesn't pmake the phone an unreliable system. In both cases there is an unbounded upper limit to the actual time of connection. But since the probability of not connecting diminishes very rapidly with time (repeated trials), it is still a useful and reliable system. The system should also take care of real failures. For instance, if the cable is broken or the station you are talking to goes down, your computer should not lead you to beleive that the message was sent sucessfully. -Mark Garrett
dgc@ucla-cs.UUCP (12/28/85)
-------
I think the various notes about ethernets miss the real question:
Just how reliable are ethernets? How do they compare in reliability
with more classical "star" nets such as that used by telephones?
Are they inherently unreliable?
To explain the last question further: Ethernets and other
non-redundant, non-star nets have the feature that ANYone on the net,
ANYwhere can at ANYtime take down the entire system, and with very
little effort. This has happened at ethernet installations.
What, for example, if the technician who installs "vampires" makes a
mistake and, while installing one, shorts the cable just while the
ethernet is being used to monitor some critical life support function?
Please don't misunderstand me. I believe that ethernets (and similar
nets) have their places, primarily in controlled environments where
the cost of catastrophic failure (that is entire system failure is not
too great). It's worth noting that AT&T, which is noted for reliable,
conservative design, stated when it first announced them, that its
electronic switches had an expectation of no more than 30 minutes
system down-time (and no more than twice) in a 20 year interval. Time
has proved that they were optimistic. We don't have as much
experience with ethernets and the small evidence that has accumulated
indicates that they will be much less reliable than classical networks.
David G. Cantor
ARPA: dgc@LOCUS.UCLA.EDU (current)
ARPA: dgc@UCLA-LOCUS.ARPA (former)
UUCP: ...!{ihnp4, randvax, sdcrdcf, ucbvax}!ucla-cs!dgc
--
David G. Cantor
ARPA: dgc@LOCUS.UCLA.EDU (current)
ARPA: dgc@UCLA-LOCUS.ARPA (former)
UUCP: ...!{ihnp4, randvax, sdcrdcf, ucbvax}!ucla-cs!dgcneal@weitek.UUCP (Neal Bedard) (12/30/85)
In article <8192@ucla-cs.ARPA>, dgc@ucla-cs.UUCP writes: > ------- > I think the various notes about ethernets miss the real question: > > Just how reliable are ethernets? [...] > > To explain the last question further: Ethernets and other > non-redundant, non-star nets have the feature that ANYone on the net, > ANYwhere can at ANYtime take down the entire system, and with very > little effort. This has happened at ethernet installations. > > What, for example, if the technician who installs "vampires" makes a > mistake and, while installing one, shorts the cable just while the > ethernet is being used to monitor some critical life support function? > I think the poster already answered his own question - usually, anything so critical is implemented with some sort of redundancy. A similar problem arises with fire alarm/life safety equipment. The answer here, too, is redundancy in the communications network, with fail-safe i/o hardware (i.e., the network does not crash if say, the power fails at one of the nodes.) Ethernet can be implemented in this way. To answer the specific case that the poster outlined, I would tend to think that the installation of a new `vampire' is something that would be a rare occurence in a up-and-running system, and would probably be a scheduled downtime sort of item. Further, situations where such critical remote telemetry functions are used (as in ICU or CCU) probably would be carried on with the usual sort of equipment anyway, and probably would not be served by Ethernet. Thus, that paticular argument of the poster's is, in my estimation, moot. -Neal -- UUCP: {turtlevax, resonex, cae780}!weitek!neal
swb@lasspvax.UUCP (Scott Brim) (01/05/86)
In article <8192@ucla-cs.ARPA> dgc@ucla-cs.UUCP (David G. Cantor) writes: >What, for example, if the technician who installs "vampires" makes a >mistake and, while installing one, shorts the cable just while the >ethernet is being used to monitor some critical life support function? >David G. Cantor This isn't the right newsgroup for this and I'm reluctant to follow up, but since it's started here: David, the only way to run an Ethernet is to pre-install (preferably cascaded) DELNIs in closets with restricted access, or (unpreferably) install them at scheduled network down times. This avoids the danger you describe, and you also have much better possibilities for problem isolation and trouble shooting, so if your cable has problems you can get it back up in a hurry. Ethernets really are quite solid (depends on the vendors you buy from though). --Scott -- Scott Brim swb@devvax.tn.cornell.edu Cornell University Theory Center {decvax,ihnp4,cmcl2,vax135}!cornell!swb 607-256-8686 swb@cornella.bitnet
ron@brl-sem.ARPA (Ron Natalie <ron>) (01/07/86)
> This isn't the right newsgroup for this and I'm reluctant to follow up, > but since it's started here: David, the only way to run an Ethernet is > to pre-install (preferably cascaded) DELNIs in closets with restricted > access, or (unpreferably) install them at scheduled network down > times. This avoids the danger you describe, and you also have much > better possibilities for problem isolation and trouble shooting, so if > your cable has problems you can get it back up in a hurry. Ethernets > really are quite solid (depends on the vendors you buy from though). > --Scott DELNI's aren't the only way. 3COM makes transceivers that go into the cable using N connectors. -Ron