MEDICAL: FRIGHTENING! Professional Discussion, Concerns, Problems, Frustration
================================================================
Medical Systems & Equipment Discussion from SIM Y2K Working Group
MODERATOR: DaveHall dhall@arinc.com (912)542-2221
================================================================
1. Author: David C. Hall ( dhall ) Date: Jul. 27 8:01 PM 1997
Due to the general interest in potential and actual YR2K problems in medical systems and equipment, we are starting a new conversation thread specifically for that infrastructure area. All those people having specific interest in medical systems and equipment are encouraged to correspond and exchange information.
2. Author: David C. Hall ( dhall ) Date: Jul. 30 12:11 AM 1997
Those of you with an interest in medical systems and equipment should check out the Centers for Disease Control web pages. They go into great detail about their Yr2K vulnerabilites and what is being done. The URL is cdc.gov
The bottom line is that the CDC is especially vulnerable to external systems and data. They have 74 active health surveillance systems collecting data from physicians, hospitals, labs, State and local health depts, Managed care organizations, etc. They are also looking at their embedded systems vulnerabilities.
3. Author: Larry Weiss ( lweiss ) Date: Jul. 31 1:52 PM 1997
I work for a health care organization in Portland Oregon, and I've yet to see anything on Y2K issues that specifically address hospital needs. Have there been any suggestions about how to go about doing an initial inventory of in-house clinical equipment?
4. Author: David C. Hall ( dhall ) Date: Aug. 1 3:59 PM 1997
As far as I can gather from various people working in this area, the only way to be sure you catch everything is to evaluate every piece of equipment that uses electricity. Some equipment you can eliminate right away, but if you do not take the time to evaluate everything, there's a good chance of missing something important.
For hospitals, I would expect a rather more stringent evaluation and audit is in order to minimize legal risks. I'll try and put together a checklist for hospitals and post it to this site later in August. If you know anyone who works with the University Hospital of Central London, I understand that they have already conducted such an inventory.
5. Author: David C. Hall ( dhall ) Date: Aug. 11 4:59 PM 1997
For those of you interested in medical systems and equipment information, the Health and Human Services person to talk to is Gayle Finch at (202) 690-5515. Her e-mail address is: gfinch@os.dhhs.gov
6. Author: Anna Williamson ( annies ) Date: Aug. 20 12:47 AM 1997
We just completed an inventory of the medical systems at Scott AFB IL and the Air Force's Medical Services Agency at Brooks AFB TX is currently conducting one Air-Force Wide. We simply did bean-counting. Anyone interested in contacting the AFMSA for further information, can email me privately.
8. Author: David C. Hall ( dhall ) Date: Aug. 23 7:16 PM 1997
There is a new health care maillist and web site for YR2K problems. The web site is rx2000.org. Check them out if you are interested. Most of the site is still mainly links to articles. Not yet much about vendors, YR2K checks, etc. I'll try and make sure that any interesting information at the site gets reposted here.
9. Author: Doug O'Boyle ( dougo ) Date: Aug. 25 10:01 AM 1997
Vendors of medical devices so far have been very quiet on Y2K, indicating there may be Y2K problems that don't want to discuss. ECRI, a non-profit group in Plymouth Meeting, Pa., has attempted to survey medical device manufacturers to learn more about Y2K problems, but so far vendors have been unresponsive. Good ECRI contact is Ken Olbrish (610-825-6000, exty. 527).
The U.S. Food and Drug Administration also is beginning to focus on this issue. FDA in 6/97 sent a letter to medical device vendors on the issue. Vendors were told to conduct safety tests on current medical devices to determine any Y2K problems. FDA contact is Tom Shope (301-443443-3314-Ext 32)
Best advice: get your lawyers involved. Have legal department write letters to medical device vendors asking them to certify that there products are Y2K compliant and, if not, when they will be made Y2K compliant. META Group research indicates a significant number of medical devices will malfunction due to Y2K. It's a Y2K area that so far has gotten little attention in the IT community - Doug O'Boyle, META Group, Reston, VA, 703-860-6614
10. Author: David C. Hall ( dhall ) Date: Sep. 2 3:30 PM 1997
Specific equipment information: Physio-Control model LIFEPAK7 defibillator/monitor (manufactured after 1985), VSM2 Vital signs monitor, and LIFESTAT 200 non-invasive blood pressure monitor are the "only products that are not YR2K compliant".
There are no plans for modifications to these products as they are no longer produced and will have been out of production for at least nine years at 2000. The manufacturer notes that the date issue will not interfere with the operation of the product, other than causing an incorrect date to print on the recorder.
I do not know what tests were run on these products. If you deal with similar products, you might want to get written confirmation of such facts. Interesting note that the company does not plan to make these compliant. I'm not sure what the normal lifetime or warranty period of such products are, but if it is more than five years, I would bee rather upset that I could not return this thing and get one that fully operates per sepcification during 2000. Gee, I sold you a product that sometimes works, but now you must pay me more money to get one that works all the time. Got to admit, this is great marketing if it works.
11. Author: Bo Hojdefors ( bch2000 ) Date: Sep. 7 2:05 PM 1997
We have electro-medical equipment in use which is more than 9 years old why the vendor's statement in point 10 is confusing & disappointing. Some devices are around 10 years old and when it comes to large installations, a life-time of up to 15 years can be found. Also, don't forget that annex 1 in our Regulations on Medical Devices (transposing the MDD, 93/42/EEC) requires that the device shall be safe for all humans and have it's performance during the INTENDED lifetime of the device...This means that it should be able to handle the year 2000 roll-over if it first was intended to be used after the millenium change.
In July I distributed recommendations to the Swedish health care providers and the medical devices companies on this subject. I believe it has been far too quiet on this issue and especially on the embedded systems. Modern healthcare is full of microcontrollers which could be affected. Some also will. In some simple tests we have seen that maintenance records systems for medical devices did not work and that an interpretive ECG recorder displayed the wrong age of the patient. Further, some radiation therapy software (not sure what applications.), defibrillator, patient booking system and patient monitors stopped working when tested.
It is too quiet from the manufacturers, though this could be due to them still checking up on this issue. Only the largest and the middle-sized device companies have at present started to tackle thee Y2K problem. Many have not yet begun looking into the issue. The awareness amongst Swedish companies is still low. This was found in a recent survey here in Sweden.
My feeling is that we are in the middle - the awareness is better in the UK and USA but there are also worse countries. In short: we recommend all manufacturers, distributors and users to make an inventory of devices that could be affected. A risk analysis (familiar to us working with the EC device directives) should be carried out in order to find critical devices which must first of all be corrected. Critical devices are not always defibrillators but could also be found in the generating plant in a hospital, in a sterilizer and in the invoicing systems or processor controlled machinery at a manufacturers premises.
We also recommend users and buyers to ask for written statements on Y2K compliance from manufacturers when buying new equipment and medical devices. My personal view is that the user should receive a statement from the manufacturer rather than to rely upon his own testing. Three or four tests can not cope with the 100 000 or more combinations of hardware and software which we have in our systems and devices. If one states a test, then it must be fully reliable and shall not invoke the user into false safety.
See also an article in the next issue of Clinica (no 773, week 37). I'm also translating the recommendations into English (not finalised). Further, there are some pending investigations among the healthcare providers on (non-compliant) medical devices.
Do you believe in a list or webpage for non-compliant devices? Any already existing?
Bo C. Hojdefors, Principal Admin. Officer, Clinical Engineer, Sweden's National Board of Health and Welfare, Medical devices, PH +46-8-783-34-99; Fax-783-32-94
12. Author: David C. Hall ( dhall ) Date: Sep. 8 10:05 AM 1997
There is as yet no web page for a listing of compliant/noncompliant devices and systems. I don't know if one will ever be established since the liability of saying a system or piece of equipment is compliant and then having one somewhere kill a patient is too great for any nonprofit organization like SIM or even a YR2K maillist like Peter de Jager's. Since anyone using a particular medical system or instrument can reconfigure it while it's being installed or upgraded, just saying it is compliant or noncompliant doesn't say much. The best we could do would be to estalish a link to the various manufacturer's pages that state whether or not their systems and equipment is compliant.
This area is like all of infrastructure, too diverse and easily changeable. We must, unfortunately, check out each of our systems and equipment ourselves. If we don't, we assume a large risk.
I for one am not willing to tell a patient or corporate manager the "I think everything will work properly come January 1, 2000". If any manufacturers would like this conversation to establish a link to their YRK notice page, let me know. I do not know of any medical manufacturer's page as of this date. If enough people and govt organizations required them to establish such pages, I think some at least would. That is the recommendation for today - if you have any power in the medical community, try and get the manufacturers to post YR2K compliancy information. At least that would give us a place to start in the inventory and assessment phase.
14. Author: David C. Hall ( dhall ) Date: Sep. 26 1:49 PM 1997
There is some new congressional testimony by the FDA folks for Congessman Horn's subcommittee. Statement was provided by Thomas Shope on 25 September, 1997. Don't yet have www URl for it, but will post when I get it.
However, the statement shows that while the FDA is getting concerned about medical device and system Y2K problems, they are not yet fully aware of the insidious nature of Y2K.
They have sent out letters in July 1997 to "13,407 medical device manufacturers, 8322 domestic manufacturers, and 5,085 foreign manufacturers" to ensure that they address this issue. However, they feel that "we do not currently believe that there will be any major impact on medical device safety". As a result of their letter "We expect manufacturers who identify products which have a date-related problem which can pose a significant risk to the patient to take the necessary action to remedy the problem".
Only a couple of problems with their approach:
1) they do not define Yr2K compliance. That is left to the vendor. As we have seen, without a strict definition of compliance, there is no way to really determine if the equipment and/or system will work at all times and in all manners specified. And especially if the system or equipment has to work in conjunction (interface) with someone else's system or equipment.
This kind of requirement "to be Y2K compliant" is essentially worthless and useless. Especially since the FDA is not asking for the vendor's compliance definition to review. They just want the vendors to check. No response is required unless the vendor finds a problem. If I was a vendor, I'd define Y2K compliance in my best interests and use the FDA letter as legal "proof" that I checked when someone sues me.
2)The FDA has not addessed the operating system or the hardware any medical system rides on or the microprocessor(s) used in the equipment. If the O/S of the PC or microprocessor the application rides on is not compliant or is compliant IN A DIFFERENT WAY, then a Y2K compliant application may (will) fail or produce erroneous data. Not good for patients, I think.
3) They also do not address how applications work with other applications if they both ride on the same PC/microprocessor. We have seen system setups where one non-compliant application will "infect" the system, thereby causing another application to fail or screw up. Again not good for patients, I think. Note that several medical manufacturers have already found that "indentical" (bought at the same time and sequentially serial numbered) machines react differently to Y2K dates because of the different BIOS and motherboards used in "identical" machines.
Another area of interest and concern is the overall schedule the FDA has put forward to complete their internal Yr2K work. It shows awareness completed in 11/96, assessment complete by 12/97, renovation complete by 12/98, validation complete by 12/98, and implementation complete by 12/98. In their own words "NIH considers the last three phases to be concurrent, rather than consecutive efforts". in other words, they are going to do renovation, validation (i assume this means testing), AND implementation all at the SAME TIME. This should be interesting. Do we believe that this will work? Has ANYONE else ever managed to successfully do all two phases, much less three, at the same time?
15. Author: David C. Hall ( dhall ) Date: Sep. 29 10:15 AM 1997
Interesting GAO report on Medicare: Medicare Transaction System: Success Depends Upon Correcting Critical Managerial and Technical Weakness, GAO/AMID-97-78, May 1997.
According to agency officials, the agency has prepared an overall Year 2000 plan for its internal systems, intends to include Medicare claims processing systems in this plan AT A FUTURE DATE, and is collecting information from systems contractors on both their progress and their planned Year 2000 activities. To date the HCFA has NOT REQUIRED SYSTEMS CONTRACTORS TO SUBMIT YEAR 2000 PLANS FOR APPROVAL (DHall note - this is mid 1997 folks!).
Further, it does not have contracts of other specific legal agreements with any contractors which state how or when the Year 2000 problem will be corrected or whether contractors will certify that they will correct the problem. HCFA has also NOT IDENTIFIED CRITICAL AREAS OF RESPONSIBILITY for Year 2000 activities.
While HFCA has been assessing the the impact of the Year 2000 on its internal systems, it HAS NOT COMPLETED A SIMILAR REVIEW OF medicare contractor's claims processing systems. (DHall note: and we all know how easy it is to fix separate systems and then interface the data when there has been NO COORDINATION, don't we).
Further, HCFA has not required its contractors to prepare an assessment of the severity of potential Year 2000 problems. Also HCFA has NO PLANS TO INDEPENDENTLY VALIDATE its contractor's strategies and test plans.
While HCFA has asked the contractors to identify their system interfaces, it had no plans for approving the contractor's approaches for addressing interface and data exchange issues. (DHall note - Great, no referee, and we can easily get closure on any nontrivial issue like this from contractor negotiations, right?).
HCFA has also not developed contingency plans in the event the Year 2000 systems fail. HCFA officials are again relying on the contractors to identify and complete the necessary work IN TIME to avoid problems. Yet, the contractors not only have not developed contingency plans, they said they do not intend to do so because they believe this is HCFA's responsibility.
And this is supposed to be a good plan and HCFA is supposed to be going great with Year 2000 work. As far as I can tell, if you depend upon Medicare, you probably will be out of luck come the end of 1999. If you generate any Medicare data, not knowing what interfaces will be necessary to correspond with HCFA or the claims processing firms might just put a crimp in your collection of funds.
How many hospitals and doctors will be able to wait several more months (years?) for their money? How will you be able to prove you requested it if the system ignores your data? Will hospitals continue to accept Medicare patients if the claims system breaks down totally? This is one area where Congress should be very concerned and I recommend that everyone let them know in no uncertain terms that we want them concerned. The report is available on the web site at access.gpo.gov
16. Author: Ed Blonski ( eblonski ) Date: Oct. 1 4:20 PM 1997
We are working at several dozen hospitals across the country doing Y2K inventory and assessemnt for classical IT/IS systems. We have only begun to do bio-med and other clinical and patient care systems. I have found very little on the sublject and the vendors I agree are very close mouth about the subject. The prime issue is that if the date is used for temporal reference only it is safe; but; what are the guarantees? Due diligence dictates that all micro processor involved devices must be examined or you leave gaping holes in any subsequent defense to litigation.
The worst part of all of this is that the CEO/CFO level still do not want to believe there is a problem
17. Author: Kevin O'Hara ( kgohara ) Date: Oct. 12 9:40 PM 1997
We are a Year 2000 consulting firm based in Sydney, Australia. We are underway with Impact Analysis of several major Australian hospitals and are putting a program together to cover another 200. Our database, which now has several hundred entries of medical and lab devices, is being continually upgraded with compliance status and we are now developing test procedures. Our database is a key part of fast tracking the work for the other hospitals.
We find that some vendors have been very helpful, but there are many others who refuse to release any information. Two that we are having problems with are GE Medical and NEC (PABX).
Another aspect that we are finding is that many vendors state that the date problem will only affect the reports and not the device operation. This (taken to the extreme) could mean that 50%+ of equipment will be reporting the wrong dates.
Could anyone assist by advising what the FDA's position is on large amounts equipment reporting wrong dates? The potential for error
appears to be too great. Also, can anyone assist with a Year 2000 contact at GE Medical and/or NEC?
Kevin O'Hara, kgohara@y2kintegration.com.au
18. Author: Bo Hojdefors ( bch2000 ) Date: Oct. 15 4:46 PM 1997
Medical devices, systems, together with supporting services are also hit by the Y2K. Device performance could be affected and in,
presumably, rare cases, the safety could be affected. Safety for the patients and safety for the users and others. Regretfully, these
embedded systems have received too little attention. The focus has been on mainframes and PCs but our devices have so far, lived their
lives in the background.
Here I would like to take the opportunity and ask the Editors of
technical magazines to publish more articles on embedded devices, microcontrollers and testing procedures!
The manufacturers of medical devices, which within the European Union are the sole responsible persons for the devices safety, are to take prime actions but also the distributors, users and authorities,
notified bodies etc have to take actions.
The manufacturers shall investigate all device/system types being used on the market including old types no longer in production (I assume here that devices still in use are within their intended lifetime). Necessary corrections and information to the users shall follow. Hopefully this action can be achieved without the use of legislative tools. The users shall also perform a risk management process in
order to find suspicious devices/systems and critical devices/systems. Since the only person with full knowledge of the device and the
software is the manufacturer, he should be contacted for a written statement on compliance/non-compliance of the device. The
manufacturer should use an appropriate definition of "Y2K-safe" (some official definitions exist in e.g. Australia, UK and Sweden) with suitable additions depending on the device and it's use. The statement should also rely upon actual tests that have been performed. Test conditions should be stated. Non-compliant critical devices/systems
should then be corrected first of all. Correction could also mean that the device is replaced with a new or another device.
Both parties are concerned: the Y2K-issue doesn't hit new devices OR old devices in use. It strikes both sides. I believe such a push and
pull process will speed things up, anyhow, that is our experience so far.
No single medical device or any other apparatus should be purchased unless the user knows that it can handle the Y2K-issue!
Corrections and new software affects the CE-marking (for AIMDD, MDD). A new software equals a new device type. The manufacturer must
not forget his production system, test/calibration equipment, services etc. The user must not forget his PAS or technical services (power supply, PMG, switchboard, networks, water, ventilation etc).
(We sent out the above recommendations (MB 16/97) in July to the health care and the industry.)
**********************************************************************
Some comments to various postings regarding lists:
I prefer the "Y2K-non-compliance" list. To put it bluntly: those who are on it want to get off ASAP and the information liability issue is easier to handle. A device not yet on this list should be treated as an unknown stranger with the inscription pre-non-compliant. (How to handle corrected devices taken off the list?)
Test conditions must always be stated. Full device designations must be stated (make, model name, type no, software version, PCB version or eventually serial number ranges or chip number ranges etc). A list with only make and general model data is usually of a very low value.
Yes, compliance information and Y2K-compliance lists should preferably come from the manufacturers but I hope there will be (where, when?) one main list or main site which gathers all this information (tables, dbases, links etc). Non-compliance lists can be compiled by the manufacturers or users etc.
I've seen some great lists at some companies but unfortunately, the information was only/at present(?) for internal use. Quite some
compliance information was also missing for some device types. It takes time to test and evaluate all devices but the manufacturers should make this information publicly available ASAP.
**********************************************************************
COMMENTS? ESPECIALLY FROM MANUFACTURERS?
Bo C. Hojdefors, Principal Administration Officer, Certified Clinical Engineer Socialstyrelsen, National Board of Health & Welfare (An executive agency of the MoH and Competent Authority for the medical devices directives) Medical Devices Section, SE-106 30 Stockholm, Sweden, bo.hojdefors@sos.se
19. Author: David C. Hall ( dhall ) Date: Oct. 28 1:21 PM 1997
The Scottish National Institute of Health (NHSiS) has established a web site to create a central pool of info on Yr2K compliance of medical devices currently in use in Scotland.
The site URL is show.scot.nhs.uk
There is very little there yet except the site. However, they are contacting manufacturers and will feed in data as they get it.
20. Author: David C. Hall ( dhall ) Date: Oct. 30 2:01 PM 1997
Interesting note seen on use of "Magic Dates" in hospital systems. One maillist person noted that many hospitals use 1/1/99 or 01/01/99 as a common length of stay default parameter. If a patient has a definite date of departure, then that date is input to the system. If their stay is of an indefinite nature, then the defult is used since the field is required to be filled. It was also noted that some embedded systems used in surgery also use this "Magic Date" for a "variety of purposes". What those purposes were/are was not defined.
One area of major concern to people who have to test systems, both software and embedded systems, is how people are using "Magic Dates". Much of this use is totally undocumented because it occured as people found out that they had to fill up an input field and did not have a "real date" handy. How many of your databases
contain such "magic dates" and how will they affect your statistical analyses once that date has passed for "real" and/or compliant systems a are installed. This is another area for overworked Yr2K people to check. What are the "Magic Dates" and how do we compensate for them
once compliant systems are in use?
===========================================================
FOR FURTHER UPDATES TO DISCUSSION, VISIT:
Society for Information Management Year 2000 Working Group
year2000.unt.edu
Free, immediate registration
If you're already registered, direct access to "embedded systems":
year2000.unt.edu
Embedded Discussion/Medical
HOUSE TESTIMONY ON EMBEDDED CHIPS, INCLUDING FDA REFERENCE:
house.gov |
