VIRUS-L Digest Monday, 4 Nov 1991 Volume 4 : Issue 209
Today's Topics:
Re: Questions about VIRLIST.TXT (PC)
Re: McAfee84 failed to remove Joshi (was Re: McAfee84 fails to remove Cascade)
(PC)
Re: VShield problem with DOS 5.0 & QEMM? (PC)
Re: Problems with McAfee's scanv84 (PC)
The 1701/1704 Virus (Ver B) [PC]
from fidonet virus conf: new virus found?
Virus Experts
Re: Boot Sector Modified (PC)
Re: Virus-Proof Machine
Re: Courses on Viri for teenagers, (General)
YAP virus (PC)
from virus fido echomail conference: new virus? (PC)
Regulation of (Medical) Software
VIRSTOP Question
where can I get a copy of "When Harlie Was One"?
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Sun, 03 Nov 91 09:09:27 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: Questions about VIRLIST.TXT (PC)
[email protected] (Raul Fernando Weber) writes:
<part of message about statistics from VIRLIST.TXT deleted>
>I assumed that each line of VIRLIST.TXT corresponds to an
>unique virus and, if there is a number between parenthesis,
>this number means the total number of known variants
>(main strain plus mutations). Adding the viruses this way,
>however, gives the discrepancies listed above. Can anybody
>from McAffe Associates explain what I'm doing wrong?
>Or how the list is to be interpreted?
You're not doing anything "wrong" at all, Mr. Weber. The VIRLIST.TXT
file is usually revised before the final release of VIRUSCAN is compiled.
Inevitably, this means that viruses will be looked for that we have not
had time to create entries for. These viruses are added to the virus count
at the end of the file, but don't actually have a listing. This usually
doesn't represent a problem since new viruses are usually not global in
scope and the VIRLIST.TXT file can be updated in the next release or so.
Additionally, variations of the existing viruses listed are often found
so these entries actually have to be updated periodically as well.
>Particularly interesting is the difference that occurs
>with version 80 of VIRLIST.TXT. In the file the total is
>714, but I got 675. The difference (39) is too big when
>compared with those from the other versions (about 5).
An example of some of those viruses we detect but aren't listed.
>Examining the list carefully I discover a great growing of
>Whale variants (from 3 to 34). I wonder if this grown really
>exists or was a typo when replacing the 3 with a 4 :-).
>The number 34 for Whale remains the same in the next versions
>of VIRLIST.TXT (82 and 84). There are really so many variants
>for the Whale virus?
There are 33 variants/mutations/iterations that the Whale virus is
capable of. Also, these exists one modified v/m/i of the virus that
is counted, for a total of 34 Whale viruses.
>Other question is related with the scan I.D. Viruses with
>the same I.D are the same virus or not? As an example, in
>version 84 both Datacrime II and Datacrime II-B have the
>same I.D. ([Crime-2]). Should they be added to the "unique
>known viruses" or to the "known viruses variants"?
DataCrime II and II-B require different search strings, but use
the same engine for removal.
>Another related question is about viruses that appear in two forms:
>a "boot" and a "file" version. They are different viruses (with
>no other relations than the name) or are the to be interpreted
>as the same virus that is able to propagate using boot sectors
>and files? If this last hypothesis is true, why the Horse Boot,
>Invader and Virus-101 (all listed as able to infect boot sectors and
>files) aren't listed in the same way?
The Horse, Invader, and V101 viruses are what's known as multipartite
("multiple part") viruses. What that means is that they infect both
files and the boot area of disks when they are accessed once the virus
has become installed in memory.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Sun, 03 Nov 91 09:14:21 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: McAfee84 failed to remove Joshi (was Re: McAfee84 fails to remove
Cascade) (PC)
[email protected] (Steve Rikli) writes:
<some of message deleted>
>As the subject says, Clean v84 couldn't handle Joshi. It discovered
>and claimed to clean it on an IBM PS2/30, but Scan discovered it
>again. Repeated attempts failed.
Can you please be more specific about what occurred? Did you receive
a message that the virus could not be safely removed, did it say it
was removed, or what? Where did VIRUSCAN (SCAN.EXE) find the virus
after cleaning? In memory or on a disk?
>Interestingly enough, Clean v76 DID handle Joshi on a CompuAdd '286.
>I thought this was *really* strange.
There are a variety of reasons that a virus could be reported after it
was claimed to be removed, these range from actual failure to remove
the virus to "ghost" images of viruses being reported as a result of
remnants of viral code left in the system.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- --
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Sun, 03 Nov 91 09:33:43 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: VShield problem with DOS 5.0 & QEMM? (PC)
[email protected],
[email protected] (
[email protected]) writes:
>Aryeh, this one's for you... I've got a question about VShield.
Okay.... :-)
>On a system using strictly DOS 5.0, the /LH works fine, however, on a
^
|
`-- MS-DOS or DR-DOS? Actually, it doesn't really
matter, but I have to be careful about this,
since there are version 5's out from both
companies.
>system using DOS 5.0 & QEMM, it won't - tells me there's no UMB's
>available... Any suggestions?
Hi Jon,
The /LH parameter was designed specifically to work with MS-DOS 5.0's
memory managing software and is not currently compatible with QEMM,
which is something we're currently working on, btw. To load VSHIELD
in an UMB with QEMM, you'll need to remove the /LH parameter from the
VSHIELD execution line and use QEMM's LOADHI command instead. Since
VSHIELD does not recognize that it's being loaded high, it will
temporarily allocate about 110Kb of memory to initialize its code
prior to installing itself as a TSR. This means that you'll need to
start with a contigious UMB of approximately 110Kb. After VSHIELD has
been installed, the memory requirement goes down to the usual (for V84
at least :-) 32.7Kb of high memory/416 bytes of conventional.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- --
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Sun, 03 Nov 91 09:44:38 +0000
>From:
[email protected] (McAfee Associates)
Subject: Re: Problems with McAfee's scanv84 (PC)
[email protected] ( ) writes:
>Has anyone else had problems with V84 of McAffee's scan program?
>Yesterday I found a third PC that won't run this version of the
>program - it hangs up and must be rebooted. Another PC gives a
>message saying the scan.exe program has been damaged - not true since
>the program works fine on most of our PCs. A third machine gave a
>parity error message when I tried to scan the disk.
Hello Kate,
Based on the information you have provided, it sounds like you are
dealing with a damaged copy of the VIRUSCAN (SCAN.EXE) program. The
reasons for this vary, but they are usually due to either due to
problems with line noise during download or the disk being crushed in
the mail, or infection by a virus (the latter effect having a possible
indicator in the fact that VIRUSCAN's anti-tamper alarm "Warning,
SCAN.EXE has been damaged..." went off). Parity Error messages are
usually the result of a physical problem with the RAM chips in the
computer, though.
At this point I would recommend that you get a fresh copy of the
VIRUSCAN program and re-check the systems in question. Please email
if you are still having problems.
Regards,
Aryeh Goretsky
McAfee Associates Technical Support
- --
- - - -
McAfee Associates | Voice (408) 988-3832 |
[email protected] (business)
4423 Cheeney Street | FAX (408) 970-9727 |
[email protected](personal)
Santa Clara, California | BBS (408) 988-4004 |
95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714
ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM
------------------------------
Date: Sun, 03 Nov 91 11:41:12 +0000
>From:
[email protected] (Robert Palmer)
Subject: The 1701/1704 Virus (Ver B) [PC]
Hi all.
Four of our PC's at work were recently infected by the 1701/1704
version B virus. The first we were aware of it was when letters etc
started dropping off the screen. It was identified by McAfee virus
scanner and dealt with by their CLEAN utility.
I would be interested to learn more about this virus as this is the
first one I have seen. Is dropping letters off the screen all is does
or does it go further?
Thanks for any help and info you can offer.
Rob.
------------------------------
Date: Sun, 03 Nov 91 08:07:00 -0500
>From:
[email protected]
Subject: from fidonet virus conf: new virus found?
forwarded from the Fidonet Virus conference
- ---------- begin forwarded message ---
To: All Message #: 3389
>From: Loek Weerd Submitted: 01 Nov 91 11:27:00
Subject: New Virus! Status: Public
Received: No Group: VIRUS (30)
Found in Delft, the Netherlands, a virus called TRAVELLER. Its an
direct infector of exe and com files. exe files grow with 1225 and
com's with 1220. It shows a message:
"TRAVELLER (C) BUPT 1991.4 don't panic I'm harmless."
There is no ather payload then the messages. The virus infects
infected files over and over and over end.... Question: Does ^[es
BUPT ring a bell ???
- --- RBBSMail v18.0b5
* Origin: Bamestra RBBS, Beemster, The Netherlands (2:512/10.0)
- ---------- end forwarded message --
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET)
University of Richmond
[email protected] (Bitnet or Internet)
Richmond, VA 23173
------------------------------
Date: Sun, 03 Nov 91 23:49:53 +0700
>From:
[email protected] (Charlie Lear)
Subject: Virus Experts
As the operator of a successful shareware business, I have a rather
paranoid attitude toward virus infection. Unfortunately, the same
cannot be said of some of my customers, nor of the "experts" they
consult.
This posting is not pointing derisively at computer users who in 90%
of cases simply don't know better; it is rather bringing to your
attention the sort of people claiming to be "experts" in the field of
virus control.
I sent a consignment of 11 1.44MB disks to a customer in a distant
town. I got a very agitated fax the next day saying that I had
appeared to have sent him blank disks.
I phoned the customer and found out that he'd tried three of the disks
in his machine and kept getting Data Error, Retry Abort Fail messages.
He had taken the disks to the local polytechnic, where the
"consultant" who had installed and set up his computer found the same
problem on two different machines. This "expert" said that it was a
fairly common error and indicated that I had sent unformatted blanks.
(My experience is that an unformatted disk gives a General failure
reading drive n: error, however we'll ignore that for the time being.)
I told the customer that the disks exhibited every sign of a viral
infection. I asked him to send the disks to me immediately.
On arrival, I put them into my quarantine system and discovered six
disks with Stoned and five with completely corrupted FATs. They
wouldn't even scan. I phoned the customer and told him of my findings.
He said he wouldn't run any floppies until I sent him an anti-viral
disk and that he'd advise the "expert" at the Polytech to check their
machines.
The next day, after he'd spoken with the "consultant", I got this fax:
"Sir,
Polytech computers are virus free, as is mine.
Possible source of contamination could be alternator's magnetic
field from engine inside courier vehicle.
Could you please direct courier service accordingly.
[this could] Also explain 5 destroyed disks if package was
placed east-west on vehicle's passenger seat."
Pretty magic-sounding alternator to me...
It's taught me a lesson. Every minute tonight during the hour and a
half it took to reformat those disks and reload the software, I told
myself, "I *MUST* remember to write protect every disk I send out, I
*MUST* remember to write protect every disk I send out, I *MUST* ..."
------------------------------
Date: 03 Nov 91 18:11:15 +0000
>From:
[email protected] (Jaap Verhage)
Subject: Re: Boot Sector Modified (PC)
[email protected] (Mike Albrecht) writes:
[...]
>However, twice now F-Prot has issued the warning:
>Warning !! - boot sector has been modified
I've had the same problem with F-oschk when making a RAM disk at
boot-up. The symptom has disappeared with the new version of F-prot
(2.0?).
- --
Regards, Jaap.
Jaap Verhage, Academic Computer Centre, State University at Utrecht, Holland.
[email protected] +<-*|*->+ I claim *every*thing and speak for myself
------------------------------
Date: Sat, 26 Oct 91 23:03:01 +0300
>From:
[email protected] (Igor G. Muttik)
Subject: Re: Virus-Proof Machine
Chris Stops (
[email protected]) proposed virus-proof
system. He writes:
> The entire operating system (i.e. BIOS, IO.SYS and MSDOS.SYS, but not
> the external commands) is held in ROM (or EPROM, or something similar.
> Upgradeable ROMs were recently discussed). Again, I will assume there
>
> [few lines skipped...]
>
> *.EXE). If we still allow executable files to be deleted, then about the
> only sort of virus left is an overwriting virus, which deletes an
> application and then creates a copy of itself using the name of the
> application. But since the applications will no longer run, it should be
> obvious that something is wrong with the machine.
Here is one obvious case when virus may still remain undetected. If file
delete function will remain available - virus can delete and substitute
any of the OS external command executable files. Virus can remove original
file and simulate its work (maybe not completely, or responding for complex
calls something like that: Internal OS error, etc.). In that case the size
of external OS utility may be the same as in original file. Or imagine
clever virus writer who succeed in combining OS external utility with virus
code resulting in file of unchanged length (DOS external utilities, for
example, has much free space inside, reserved for data buffers, etc.).
> Not only can no virus modify it, but no extensions can be added either,
> for example, new device drivers. The virus proof way around this is that
> new drivers are supplied on ROMs which can be plugged into the machine,
> and patched into the O/S during initialisation. A slightly less secure
I think that virus cannot be stopped on machines with read/write media used
to store executables. Only ultimate solution is to place *ALL* executable
code in ROMs/EPROMs/CDROMs on factories. But what about code, produced by
assemblers/compilers ? Use only RAMdrive ?
I think that viruses can still live in Chris Virus-Proof machine, but the
main objective of their activity may become .OBJ and .LIB files (and also
BAT files). It is obvious case of executable code. But if you protect them
as executables any work with compilers will become impossible.
Finally, I think that it is hard to work effectively on Chris Virus-Proof
machine because of significant flexibility loss. I agree with Fred Waller
- - we do not need Virus-Proof machine, Virus-Resistant machine is much more
attractive. We need not to lose flexibility because ofwide use of ROMs, while
possibility of infection in true Virus-Resistant machine would be low enough
to eliminate epidemies.
Best regards,
/----------------------\ /-------------------------------------------------\
| Igor G. Muttik, Ph.D. | "...it is a thing you can easily explain twice |
| Moscow, Russia | before anybody knows what you are talking about." |
|
[email protected] | Winnie-the-Pooh |
\----------------------/ \-------------------------------------------------/
------------------------------
Date: Mon, 04 Nov 91 00:37:25 +0000
>From:
[email protected] (Liam Routt)
Subject: Re: Courses on Viri for teenagers, (General)
Comment only, flame not intended:
I find it interesting that people are so convinced that evil (or in
the case of viriuses: writing viriuses) is so appealing that the youth are
unable to resist it...
As a teenager I was interested in knowing about viruses because of the
challenge they provided - protection against them. Maybe I am just an eternal
optimitst, but I think that through further education one can turn the resource
that is the youth to the service of good, rather than evil; by hiding away the
techniques associated with virius creation, you make the that knowledge very
exciting - the allure of forbidden knowledge. If you instead teach such
things, and with them an attitude of responsibility, then I think more good
will come than evil...
- --
Liam Routt
"Murder by Pirates is Good!" Senior Software Engineer
-The Princess Bride Bull Information Systems
Melbourne, AUSTRALIA
------------------------------
Date: Mon, 04 Nov 91 11:45:30 +0700
>From: "Jan R. Terpstra" <
[email protected]>
Subject: YAP virus (PC)
In reply to Frisk's boggeld mind about the origin of the file YAP.COM
of 6258 bytes, that most likely came via me. I got that file sent to
my FIDO net (2:512/10.) from a fellow sysop in Italy somewhere in June
of this year. I'm usually very careful with giving out samples. I
sent a copy of it to both Dave Chess and Righard Zwienenberg for
further investigation.
Just wondering how you got your copy :-)
<JT>
UDA (Usual disclaimers apply)
------------------------------
Date: Mon, 04 Nov 91 07:14:00 -0500
>From:
[email protected]
Subject: from virus fido echomail conference: new virus? (PC)
Hi. I found the following message in the FIDO echomail VIRUS. Unfortunately,
the description is somewhat incomplete (seems that the user is more of an
user than a virus-researcher).
Regards, Claude.
- ----- begin forwarded message --
To: All Message #: 3953
>From: Felix V.Leitner Submitted: 29 Oct 91 13:43:00
Subject: New Virus ? Status: Public
Received: No Group: VIRUS (30)
Hi !
Yesterday I obviously had a virus in my system, maybe it is still there!
SCAN 84 did not find any virus, VIRX 1.7 neither, TBSCAN with my latest
database from august '91 and TNT-Virus 8.0 and FPROT 1.16 neither.
This virus is a memory-resident, non-direct-action virus, infecting
EXE files (maybe .COM, too ?). Size increase seems to be between 1k
and 2k.
When I run SCAN the second time it reported "SCAN.EXE is damaged.",
the available memory had decreased, I don't know how much. I copied
the infected SCAN to a TMP directory and unzipped another one. This
one was smaller. A few minutes later I discovered that the infected
SCAN.EXE (I renamed it into INFECTED.EXE) had the same length than the
"fresh" one. So this virus seems to remove itself from infected
files, I think it does so when it detects to be debugged or something.
I don't know. After I rebooted I engaged all the virus scanners, but
none found anything wrong.
I panicked and deleted a few .EXE files I had got this afternoon (I
had them zipped on disk), but I don't really know which files are
infected, because this virus is not detected by any scanner known to
me.
Does someone recognize these symptoms ?
What is (or was) this virus ? Maybe I deleted it unknowingly (and
unwillingly)? Because after looking at a few files from a local BBS I
deleted them because they were too bad, and now I don't know if the
virus was in these files !
It confused me that VPIC refused to run, although it was not damaged.
After I rebooted and tried again it run perfectly well! It said it
was damaged and won't run. I don't understand all this and I think
I'm going to explore my HD a little better in future 8-!
Greetings, Felix
- ---
* Origin: memory allocation error, system halted (2:242/33.4)
- ----- end forwarded message
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET)
University of Richmond
[email protected] (Bitnet or Internet)
Richmond, VA 23173
------------------------------
Date: Mon, 04 Nov 91 09:10:45 -0500
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Regulation of (Medical) Software
(everything from here down to the next >>>>>>>>>>>>>>>>>>> is a
posting from Peter Neumann's RISKS newsgroup)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>From: HORN%
[email protected]
Subject: FDA-HIMA Conference on Regulation of Software
On 9 and 10 October 1991, the Health Industry Manufacturers
Association (HIMA) and the Food and Drug Authority (FDA) had a joint
conference to explain FDA regulation of software. The following is a
summary of highlights from that conference. (If you are actually
involved with potentially regulated software, contact the FDA for the
complete rules and contact an expert. This area is as complex in its
details as the tax laws.)
First, what does the FDA regulate?
1) Under the 1936 Act, any medical device, drug, or practice.
2) Under the 1990 Safe Medical Devices Act, authority to examine
devices was expanded.
Software may be involved in any of four ways:
1) It may be a device
2) It may be used in the manufacture of a device or drug
3) It may be used in record keeping
4) It may be contracted or purchased from a third party for one of the above.
FDA approval involves two steps: approval to market and approval to
sell. Approval to market involves one of two things: 1) A PMA for new
medical technologies (see an expert now). 2) A 510(k) for equivalent
medical technologies (substitutes for some previously approved
device).
For a 510(k) approval there are three categories of approval difficulty based
upon the hazard to patients and others:
1) minor, little risk of injury either direct or indirect
2) moderate,
3) major, risk of death
An example of a minor is a urological machine comprised of a funnel,
flask, scale, and computer for measuring urinary function. It is very
hard to hurt anyone when this machine malfunctions. A misdiagnosis
injury is also very unlikely because many other measurements and human
interventions will take place before a decision is made. An example
of major is the remote programmer for a pacemaker. Death is a likely
direct result of a malfunction.
The FDA examination for a 510(k) is proportionate to the risk. For a
minor risk item the FDA will probably accept a detailed development
plan, and defendable development, configuration control, and
validation methodologies. For a major risk item, they will examine
all the validation results in detail and demand thorough hazard
analysis. They will challenge many details to assure themselves by
spot inspection that the validation is probably complete.
For more details ask the FDA for a copy of the 510(k) reviewers
guidance. This is the document used by the 510(k) reviewer and is
freely available to the public.
Then comes approval to sell. This is based upon a Good Manufacturing
Practices (GMP) inspection. Again, the inspection detail will be a
function of the risk to the patient and others.
For a minor risk item, they might not inspect at all. Most likely,
they just verify by spot checks that the claims made in the 510(k) are
being kept. For a major risk item, they may inspect a lot. If
someone actually gets hurt, expect an army of inspectors swarming over
everything.
For software there was little surprise that the inspectors verify all
the claims in the 510(k). The surprise was in how ancillary
manufacturing software and purchased software are treated. First, any
software might be inspected. If its failure could lead to injury it
is subject to inspection. This means that a spreadsheet program on a
PC will be subject to inspection if it is used to compute a quality
parameter. Second, there is no assumption of validity for off the
shelf software.
For more details, the FDA provides copies of GMP practices regulations
to anyone who asks.
In a recent GMP inspection a drug maker was hit with violation notices
because an off-line PC was being used to run a statistical process
control package as part of a process improvement effort. The SPC was
not directly used to control manufacture or determine quality. Other
equipment handled that. The problems listed were:
1) The PC was not under strict hardware maintenance schedule with
change control and serial number tracking of components.
2) The specific PC hardware configuration was not validated.
3) The SPC program validation was inadequate (the drug manufacturer had
run and documented test cases before placing it in use).
4) The PC was not regularly backed up
5) There were no documented procedures for disk space management.
6) There was not a documented procedure and records for software
change and update validation.
7) There was not sufficient security and auditing to assure that
the software was not changed during use.
The manufacturer was told to fix these problems. If they were not fixed, the
factory would eventually be shut down.
This attention to software is new at the FDA. It went into effect
this summer and more regulations take effect this fall.
The other area that is catching people by surprise is the extent of
the definition of device and manufacture. Most recently, the makers
of blood bank software were hit. They had not previously realized
that the database software for tracking blood donations was a medical
device and probably a class 3 device. Big time mistake. About a
third of the blood bank software vendors have been closed, and their
software recalled by the FDA. There is an open issue around hospital
and laboratory information systems. These may also be medical devices
depending upon how they are used.
As an example: a mainframe manufacturer M ran an advertisement
claiming that since hospital X used M's machines, it could deliver
superior care. By doing this, manufacturer M has made a medical
efficacy claim and converted their mainframe into a medical device.
In theory, they must now get a 510(k), GMP inspected, prove the safety
of their mainframe, and demonstrate that it does in fact improve
medical care. In practice, they get a phone call telling them ``Don't
be fools. Stop running that ad. You don't realize what you are
doing.''
The HIS and LIS vendors are at more risk. If a failure in an HIS or
LIS software leads to incorrect recording of critical patient
information that can then cause death, they may be class 3. It
depends upon what other safeguards exist. If the usage label does not
require other safeguards exist, class 3 may follow.
The FDA approach differs from that of MoD and others in that there is
no FDA approved methodology. The FDA will not state that anything is
guaranteed acceptable. Instead you are always subject to challenge.
They claim that this allows them to accept new methodologies as they
are proven. It also lets them reject anything and not expose them to
the risk of making a decision. If anything goes wrong, its your fault
and you (not the FDA) are liable.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
I have posted this entire commentary because IMHO it is significant.
In a time when doctors and hoptials are increasingly relying on PCs to
manage patient's records and all other phases of treatment, some form
of regulation/certification in the wake of numerous recorded
intrusions by hackers and viruses was inevitable. The real question is
"how far will it go".
Again IMHO, the first step must be some form of secure, certifiable
operating system. Though much derided, MS-DOS (or DR-DOS), is an
effective and widely used O/S. Most applications operate under these
libraries & I would be surprised to see any sudden migration away from
them.
ERGO, what is needed is a certifiable (I know 8*) operating system or
shell (more difficult but if MicroSoft & Digital Research continue to
be disinterested -well, maybe not DR-, encapsulation will be the only
answer).
In any event, it may well be the Fed, in the guise of Medical safety,
that will finally force integrity management on the PC. Well, we get
tired of waiting for the lawyers to do someting useful 8*).
Padgett
------------------------------
Date: 04 Nov 91 07:36:00 -0500
>From: "19296, JAFFE, BRUCE" <
[email protected]>
Subject: VIRSTOP Question
What does the message "Warning: This version of the program is rather
old. A new version should be installed." mean? This is from VIRSTOP
version 2.00.
------------------------------
Date: Mon, 04 Nov 91 09:05:44 -0600
>From:
[email protected] (JESUS BARRERA RAMOS)
Subject: where can I get a copy of "When Harlie Was One"?
Hi all!
c...I've been lookin' for a copy of the book "When Harley Was One" but
I've found it yet...does somebody know where can I get it?...please..I'd
thank ya more than a lot..c ya. thanx.
Eqix
[email protected]
[email protected]
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 209]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
