The day started bright and early at 7 am with the…
GE Breakfast Symposium
Presented by Elliot Sloan and Leanne Cordisco, the symposium presented a vision of the future of the biomedical engineer. Elliot started off, describing how we got to where we are.
“May you live in interesting times…”
The issue that started all this – biomedical engineering – was electrical safety. Ralph Nader’s shocking expose on a rash of hospital patient deaths from electrocution stirred both the public and the industry. Nader’s
shameless self promotion consumer advocacy resulted in congressional hearings, new FDA regulatory authority, and the creation of the biomedical engineering role in hospitals.
Then in 1977, the big issue was gas safety. Changes like DISS standard gas fittings, O2 low-pressure cutoffs and PO2 monitoring were the result. Already the interactions between systems of systems were creating risks that resulted in use errors, patient injury and death.
Classic systems engineering was first applied to solve anesthesia deaths in 1991. The need for systems engineering has only grown over the years, as complexity affects multiple systems in unexpected ways.
“Be careful what you ask for.”
Back in the age of the IBM 360 main frame computer, visionaries were first imagining computers’ ability to transform the delivery of health care. We’re only now approaching this initial vision of the computerized hospital. Examples of this include CIMIT’s ORF (operating room of the future) which offers a more safe environment with better outcomes, that can support almost twice the surgical case volume compared to a conventional surgical suite.
At the same time, the government is automating every citizen’s health data, from genetic information gathered at birth to a complete longitudinal record to death. The realization of this vision is of tremendous scope and complexity. This will transform health care, for both those who deliver it and those who are consumers.
“We can’t solve problems by using the same kind of thinking we used when we created them.” Einstein
At the IEEE they’re suggesting that we’re entering a period of systems of systems — all of which are interdependent, but most or all we can’t control. For example an ambulance service that uses Google Earth to locate patients; what if problems in Google Earth impacts the ability of the ambulance driver to locate the patient? What can the ambulance service do? How are problems like this addressed?
Elliot also talked about the Department of Defense’s “Vision 2010” for a real time networked battle space that is end user oriented. The idea here is that there will be a civilian dividend for this pervasive information architecture and applying it to health care.
Elliot extracted the need to respond quickly to requirements, like when the Bird Flu transforms to be human transferable. Rather than the classic waterfall approach to software life cycle management, there’s a need for a System of Systems Engineering model.
Risk federation and IEC 80001
Leanne shifted Elliot’s visionary view of the industry to a specific example of the IHE interoperability show case from the last HIMSS in 2008. This system of systems is not unlike what can be found in hospitals today.
Partially in response to this complexity, the IEC is creating a draft voluntary standard to mitigate the risk of creating unintended systems of systems. This effort, IEC 80001, targets networked medical devices, with a unified risk management process. (You can read a series of posts on IEC 80001 here.)
The standard places responsibilities on:
- Medical device vendors
- IT technology providers
- Responsible organization (provider)
- Top management
- Medical IT integration risk manager
- IT network maintainer
These last two responsibilities represent new positions in the hospital.
The Medical IT Risk Manager will be responsible for:
- Collect all relevant information from medical device vendors
- Plan the integration of medical devices in accordance with vendors instructions
- Perform risk management on the resulting enterprise network and attached medical devices
Much like HIPAA, this standard is not proscriptive, but allows the provider organization to implement a solution that best fits their unique situation.
AAMI/ACCE/HIMSS Clinical Engineer
The role of Medical IT Risk Manager requires a special skill set. The AAMI, ACCE and HIMSS organizations are working to develop the training so that provider organizations will have the human resources to fill these new positions with capable and talented people.
Q: I asked, when the standard is complete, who do they think will drive adoption?
A: No organizations are apparently waiting in the wings. The joint commission is a possibility, and the legal community might create compelling reasons to implement the standard (to minimize legal risk).
Q: Define systems of systems.
A: Complexity engineering – whole disparate systems that can’t be decomposed or disconnected. Emergent behavior is another characteristic of systems of systems – the weird stuff people do to resist or adjust to complex systems. For example, Ross Koppel did a study capturing all the many ways nurses disrupt the use of bar code meds administration systems. Another characteristic of systems of systems have results or outputs that are not binary but are rather fuzzy.
Q: I asked, compare FDA’s QSR to the 80001 risk management process.
A: In a medical device vendor, employees and business decisions are all very controlled. The 80001 standard recognizes that as soon as you place the regulated medical device system into a hospital, there are myriad unknown variables.
Q: What about the costs associated with complying with this new standard, is there any plan to phase this in to mitigate the financial impact?
Q: What about organizations outside the hospital that don’t have an IT department or biomedical engineers, and lack the resources to implement a risk management process?
A: Great question, don’t know.
More will be added on additional presentations over the next couple days. Check back for updates.