- Email: [email protected]
information systems
Chapter 88
Forensics and accident/ incident investigations for device/information systems Elliot B. Sloanea,b, Ricardo J. Silvab,c a
Foundation for Living, Wellness, and Health, Osprey, FL, United States, bComputing Sciences, Villanova University, Villanova, PA, United States, cFoundation for Living, Wellness, and Health, Orlando, FL, United States
Introduction When ECRI Institute was being created in the late 1960s and early 1970s, the founder, Dr. Joel J. Nobel took part in FDA medical device safety hearings at the US FDA. (https:// www.ecri.org/about/ecri-institute-history-50-years-ofadvancing-evidence-based-healthcare and https://cdn.hpnonline.com/inside/2008-09/0809-UpClose.html). Almost immediately, ECRI created what was, and is, known as the Problem Reporting Network (PRN). The author was among many of the ECRI staff who used these confidential PRN complaints, typically from hospitals, to trigger independent product investigations not unlike the way the NTSB investigates airplane crashes. In fact, Dr. Nobel said he patterned the investigations after the Navy’s problem investigation processes that he observed as a young submarine medical officer in the 1960s. Over the past 50 years, these early PRN investigation practices pioneered an entire ECRI specialization in Accidents and Medical Forensics. Today, numerous further subspecialties have emerged, including expert witness and investigation of a wide range of medical products including implants, diagnostic and monitoring devices, and medical operations and procedures. Because ECRI is a 501(c)(3) nonprofit organization whose services have always included education, training, and publication, many of the underlying methodologies have been published and openly described to the US and international industry. In this chapter, we will use two main references: ECRI’s expert Dr. Hansel’s brief 2008 overview, and ECRI’s Emeritus VP’s 2007 workshop for the Saudi FDA (Hansel, 2008). In brief, Hansel documents three priorities for accident investigations: (1) protect the patient, (2) preserve the evidence, and (3) communicate with the family and appropriate authorities. However, as shown in Fig. 1 a fourth, fifth, and
644
sixth priorities are unstated but are, in fact, part and parcel of ECRI’s processes (4) investigate and understand the cause of the problem; (5) work with the manufacturer and user to identify the best corrective countermeasures to prevent recurrence; and (6) communicate the problem and resolution to the industry, press, and government as quickly and appropriately as possible. Mr. Bruley’s Saudi FDA workshop provides much more detail about the preservation and investigation stages, including assessment of environmental, user, and, of course, inherent device characteristics. Mr. Bruley’s workshop also goes into excellent detail about the preservation of evidence and, just as important, identifying and preservation of the interfaces between the device, user, and environment. Bruley has continued to contribute to the field’s wisdom in his post-ECRi career (www.themedicaldetective.com), and this chapter explains ways to apply his accident and medical forensics methods for the 21st Century information and communication age.
A brief History of relevant ICT and mHealth innovations 2001—Golden age of clinical engineers (CE) due to information technology (IT) integration (https://www.ncbi. nlm.nih.gov/pubmed/11383312). 2008/09—Intro of smartphones, apps (https://apple-history. com/iphone and https://apple-history.com/ipad). 2011/12—emergence of mHealth ecosystems and marketplace (https://www.microsoft.com/en-us/research/ event/mhealth-summit-2010/). 2013/12—growth of cloud computing into a pervasive, global marketplace (https://www.dataversity.net/ brief-history-cloud-computing/).
Clinical Engineering Handbook. https://doi.org/10.1016/B978-0-12-813467-2.00089-4 Copyright © 2020 Elsevier Inc. All rights reserved.
Forensics and accident/incident investigations Chapter | 88 645
WƌŽƚĞĐƚ
WƌŽƚĞĐƚƚŚĞƉĂƟĞŶƚ
WƌĞƐĞƌǀĞ
&ŽƌĞŶƐŝĐƐĂŶĚ ĂĐĐŝĚĞŶƚͬŝŶĐŝĚĞŶƚ ŝŶǀĞƐƟŐĂƟŽŶƐ
WƌĞƐĞƌǀĞƚŚĞĞǀŝĚĞŶĐĞ
ŽŵŵƵŶŝĐĂƚĞ ƉƌŽďůĞŵ /ŶǀĞƐƟŐĂƚĞ ĂŶĚ ƵŶĚĞƌƐƚĂŶĚ
ŽŵŵƵŶŝĐĂƚĞǁŝƚŚƚŚĞĨĂŵŝůLJĂŶĚĂƉƉƌŽƉƌŝĂƚĞĂƵƚŚŽƌŝƟĞƐ
/ŶǀĞƐƟŐĂƚĞĂŶĚƵŶĚĞƌƐƚĂŶĚƚŚĞĐĂƵƐĞŽĨƚŚĞƉƌŽďůĞŵ
tŽƌŬǁŝƚŚƚŚĞŵĂŶƵĨĂĐƚƵƌĞƌĂŶĚƵƐĞƌƚŽŝĚĞŶƟĨLJƚŚĞďĞƐƚĐŽƌƌĞĐƟǀĞ ĐŽƵŶƚĞƌŵĞĂƐƵƌĞƐƚŽƉƌĞǀĞŶƚƌĞĐƵƌƌĞŶĐĞ
/ĚĞŶƟĨLJ
ŽŵŵƵŶŝĐĂƚĞ ŽŵŵƵŶŝĐĂƚĞƚŚĞƉƌŽďůĞŵĂŶĚƌĞƐŽůƵƟŽŶƚŽƚŚĞŝŶĚƵƐƚƌLJ͕ƉƌĞƐƐ͕ĂŶĚ ŐŽǀĞƌŶŵĞŶƚĂƐƋƵŝĐŬůLJĂŶĚĂƉƉƌŽƉƌŝĂƚĞůLJĂƐƉŽƐƐŝďůĞ ƌĞƐŽůƵƟŽŶ FIG. 1
2016/17—commodity expansion of IoT products to the home market, such as Amazon Echo (Alexa) and Google Home (https://spectrum.ieee.org/consumer-electronics/gadgets/ the-consumer-electronics-hall-of-fame-amazon-echo-dot).
Procedures The following information provides an outline of ideas and concepts to extend the Bruley/Hansel/ECRI accident and medical forensics approaches when information and communication technologies (ICT) are embedded in—or interdependent parts of—a medical accident report and subsequent investigation. To be clear, a growing challenge for any such investigations is to determine what and where is the "medical device" that was involved. Today, few stand-alone medical devices exist. Yes, there are some individual heart monitors, blood pressure measurement devices, defibrillators, or infusion pumps in the market. Even those, however, are likely to have one or more microprocessors and embedded firmware that transforms sensor/transducer/actuator/user data for storage, display, analysis, and, in some cases, administration of therapeutic intervention. Over the past decades, however, more and more hospitals have implemented wireless networks that allow devices to send or receive data from other devices (e.g., a smart infusion system) or to one or more electronic medical record systems. (http://hitsp.org/ConstructSet_ Details.aspx?&PrefixAlpha=5&PrefixNumeric=905). In most hospitals, and many physician practices, devices are enmeshed in a wired and wireless network of ICT
t echnologies that may even include remote cloud and storage solutions in addition to the local network technologies. Consider a reasonably common potential incident scenario, such as a drug overdose (or underdose) that harms a patient. Determining if the infusion pump, smart controller, pharmacy bar coding, network communication, or EMR computerized provider order entry system caused, or contributed, to the incident may not be a simple matter (Fig. 2). The ideas and concerns itemized below will assist readers in developing their own procedures when ICT is part of the potential problem. Pilots are taught that when they get in trouble, such as accidentally flying into a cloud and losing sight of land, they should communicate, confess, and comply, i.e., immediately communicate the problem to air traffic control; confess the details of the problem and risks being faced; and then comply with the instructions they receive for a safe recovery. In addition, as soon as awareness of the incident communicated, the user(s)/investigators must immediately begin to document EVERY aspect of the incident with time-stamped photos, videos, and/or typed, written, or audio notes. Protect patient(s) and patient identity. Protect staff and bystanders. Protect environment. Notify Senior Management with respect to disaster/risk/PR/ legal counsel. Identify institutional PR liaison(s), qualified and authorized to speak to press, family, staff.
646 SECTION | 9 Management of digital healthcare, information systems, and health informatics innovations
FIG. 2 Diagram of devices, actors, and information flow in modern accident investigations of ICT-connected medical products.
Identify internal or external lead investigator who is qualified and authorized to investigate and document sensitive systems and information. Protect and preserve evidence. Ensure patient, other persons, and environment are all clearly documented and timestamped with notes, photos, or other means. Disconnect from networks and Internet and all other devices. Trace and document all interconnected and interdependent systems immediately. Must identify if other devices/systems/subsystems may be compromised. If so each such system/subsystem may need to go through this entire set of procedures immediately and simultaneously. Hibernate device(s) if operating system (OS) allows. In Windows OS, the "hibernate" mode preserves all current settings and activities. Shutdown or restart will likely clear and reset everything, and possibly destroy most or all prior data. ALSO, shutdown or restart COULD trigger OS, antivirus, software, and even firmware updates, any or all of which could destroy critical evidence. Disconnect device(s) from alternating current (AC) power. However, this can only be done if the device is in a hibernation mode. Otherwise, unplugging from AC power runs the risk of an abrupt forced shutdown and cold/hard restart, again risking loss of all prior data and settings. Carefully consider removing battery/batteries, only if evidence/data will not be put at risk. Document the entire environment. Do not repower or reconnect anything!
Document externally, via examination or from computerized maintenance management system (CMMS) details such as system/subsystem/device serial numbers (SNs), revision levels, passwords, configuration specifics, interoperability capabilities and connections, customization info. Diagramming may help. Develop a few failure mode and effects analysis (FMEA) fishbone diagrams, brainstorming potential causes, gaps, considerations, risks. Develop forensic analysis toolkit needs, options. May need HIPAA audit logs, network access logs, UserID role authorization details, device/system/environment change and/or update authorizations and logs. Consider non-destructive cloning of hard drives and any preserved flash memory on the device.
Summary This chapter is an initial exploration of how to extend past problem, accident, and forensic reporting and analysis methods when computerized technologies are involved. Merely sequestering an individual medical device will not likely provide sufficient information about the environment and/or user interactions with the patient and/or device, because many other software and hardware components and systems may have an interdependent role in safe operation and outcomes. Readers who intend to explore these challenges more closely may be well advised to obtain the latest copy of the free NIST Security Incident Handling Guide (https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/ final) and the free NIST Contingency Planning Guide for
Forensics and accident/incident investigations Chapter | 88 647
Federal Information Systems (https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final). These NIST and other related free NIST Special Publications can be invaluable resources for clinical engineers and forensics investigators who are preparing to support the growing complexity of interoperable ICT and medical device systems. (https://csrc. nist.gov/publications/sp).
Reference Hansel, B.C., 2008. Risk Versus Liability: Managing Device Incident Reports. Biomed. Instrument. Technol. 2008, 42 (1), 61–63. https:// doi.org/10.2345/0899-8205(2008)42[61:RVLMDI]2.0.CO;2. and https://www.sfda.gov.sa/en/medicaldevices/gcc/Workshops/ Documents/1DeviceAccidents_RecognitionandInvestigationProcess_ SFDA.pdf.
Forensics and accident/ incident investigations for device/information systems Elliot B. Sloanea,b, Ricardo J. Silvab,c a
Foundation for Living, Wellness, and Health, Osprey, FL, United States, bComputing Sciences, Villanova University, Villanova, PA, United States, cFoundation for Living, Wellness, and Health, Orlando, FL, United States
Introduction When ECRI Institute was being created in the late 1960s and early 1970s, the founder, Dr. Joel J. Nobel took part in FDA medical device safety hearings at the US FDA. (https:// www.ecri.org/about/ecri-institute-history-50-years-ofadvancing-evidence-based-healthcare and https://cdn.hpnonline.com/inside/2008-09/0809-UpClose.html). Almost immediately, ECRI created what was, and is, known as the Problem Reporting Network (PRN). The author was among many of the ECRI staff who used these confidential PRN complaints, typically from hospitals, to trigger independent product investigations not unlike the way the NTSB investigates airplane crashes. In fact, Dr. Nobel said he patterned the investigations after the Navy’s problem investigation processes that he observed as a young submarine medical officer in the 1960s. Over the past 50 years, these early PRN investigation practices pioneered an entire ECRI specialization in Accidents and Medical Forensics. Today, numerous further subspecialties have emerged, including expert witness and investigation of a wide range of medical products including implants, diagnostic and monitoring devices, and medical operations and procedures. Because ECRI is a 501(c)(3) nonprofit organization whose services have always included education, training, and publication, many of the underlying methodologies have been published and openly described to the US and international industry. In this chapter, we will use two main references: ECRI’s expert Dr. Hansel’s brief 2008 overview, and ECRI’s Emeritus VP’s 2007 workshop for the Saudi FDA (Hansel, 2008). In brief, Hansel documents three priorities for accident investigations: (1) protect the patient, (2) preserve the evidence, and (3) communicate with the family and appropriate authorities. However, as shown in Fig. 1 a fourth, fifth, and
644
sixth priorities are unstated but are, in fact, part and parcel of ECRI’s processes (4) investigate and understand the cause of the problem; (5) work with the manufacturer and user to identify the best corrective countermeasures to prevent recurrence; and (6) communicate the problem and resolution to the industry, press, and government as quickly and appropriately as possible. Mr. Bruley’s Saudi FDA workshop provides much more detail about the preservation and investigation stages, including assessment of environmental, user, and, of course, inherent device characteristics. Mr. Bruley’s workshop also goes into excellent detail about the preservation of evidence and, just as important, identifying and preservation of the interfaces between the device, user, and environment. Bruley has continued to contribute to the field’s wisdom in his post-ECRi career (www.themedicaldetective.com), and this chapter explains ways to apply his accident and medical forensics methods for the 21st Century information and communication age.
A brief History of relevant ICT and mHealth innovations 2001—Golden age of clinical engineers (CE) due to information technology (IT) integration (https://www.ncbi. nlm.nih.gov/pubmed/11383312). 2008/09—Intro of smartphones, apps (https://apple-history. com/iphone and https://apple-history.com/ipad). 2011/12—emergence of mHealth ecosystems and marketplace (https://www.microsoft.com/en-us/research/ event/mhealth-summit-2010/). 2013/12—growth of cloud computing into a pervasive, global marketplace (https://www.dataversity.net/ brief-history-cloud-computing/).
Clinical Engineering Handbook. https://doi.org/10.1016/B978-0-12-813467-2.00089-4 Copyright © 2020 Elsevier Inc. All rights reserved.
Forensics and accident/incident investigations Chapter | 88 645
WƌŽƚĞĐƚ
WƌŽƚĞĐƚƚŚĞƉĂƟĞŶƚ
WƌĞƐĞƌǀĞ
&ŽƌĞŶƐŝĐƐĂŶĚ ĂĐĐŝĚĞŶƚͬŝŶĐŝĚĞŶƚ ŝŶǀĞƐƟŐĂƟŽŶƐ
WƌĞƐĞƌǀĞƚŚĞĞǀŝĚĞŶĐĞ
ŽŵŵƵŶŝĐĂƚĞ ƉƌŽďůĞŵ /ŶǀĞƐƟŐĂƚĞ ĂŶĚ ƵŶĚĞƌƐƚĂŶĚ
ŽŵŵƵŶŝĐĂƚĞǁŝƚŚƚŚĞĨĂŵŝůLJĂŶĚĂƉƉƌŽƉƌŝĂƚĞĂƵƚŚŽƌŝƟĞƐ
/ŶǀĞƐƟŐĂƚĞĂŶĚƵŶĚĞƌƐƚĂŶĚƚŚĞĐĂƵƐĞŽĨƚŚĞƉƌŽďůĞŵ
tŽƌŬǁŝƚŚƚŚĞŵĂŶƵĨĂĐƚƵƌĞƌĂŶĚƵƐĞƌƚŽŝĚĞŶƟĨLJƚŚĞďĞƐƚĐŽƌƌĞĐƟǀĞ ĐŽƵŶƚĞƌŵĞĂƐƵƌĞƐƚŽƉƌĞǀĞŶƚƌĞĐƵƌƌĞŶĐĞ
/ĚĞŶƟĨLJ
ŽŵŵƵŶŝĐĂƚĞ ŽŵŵƵŶŝĐĂƚĞƚŚĞƉƌŽďůĞŵĂŶĚƌĞƐŽůƵƟŽŶƚŽƚŚĞŝŶĚƵƐƚƌLJ͕ƉƌĞƐƐ͕ĂŶĚ ŐŽǀĞƌŶŵĞŶƚĂƐƋƵŝĐŬůLJĂŶĚĂƉƉƌŽƉƌŝĂƚĞůLJĂƐƉŽƐƐŝďůĞ ƌĞƐŽůƵƟŽŶ FIG. 1
2016/17—commodity expansion of IoT products to the home market, such as Amazon Echo (Alexa) and Google Home (https://spectrum.ieee.org/consumer-electronics/gadgets/ the-consumer-electronics-hall-of-fame-amazon-echo-dot).
Procedures The following information provides an outline of ideas and concepts to extend the Bruley/Hansel/ECRI accident and medical forensics approaches when information and communication technologies (ICT) are embedded in—or interdependent parts of—a medical accident report and subsequent investigation. To be clear, a growing challenge for any such investigations is to determine what and where is the "medical device" that was involved. Today, few stand-alone medical devices exist. Yes, there are some individual heart monitors, blood pressure measurement devices, defibrillators, or infusion pumps in the market. Even those, however, are likely to have one or more microprocessors and embedded firmware that transforms sensor/transducer/actuator/user data for storage, display, analysis, and, in some cases, administration of therapeutic intervention. Over the past decades, however, more and more hospitals have implemented wireless networks that allow devices to send or receive data from other devices (e.g., a smart infusion system) or to one or more electronic medical record systems. (http://hitsp.org/ConstructSet_ Details.aspx?&PrefixAlpha=5&PrefixNumeric=905). In most hospitals, and many physician practices, devices are enmeshed in a wired and wireless network of ICT
t echnologies that may even include remote cloud and storage solutions in addition to the local network technologies. Consider a reasonably common potential incident scenario, such as a drug overdose (or underdose) that harms a patient. Determining if the infusion pump, smart controller, pharmacy bar coding, network communication, or EMR computerized provider order entry system caused, or contributed, to the incident may not be a simple matter (Fig. 2). The ideas and concerns itemized below will assist readers in developing their own procedures when ICT is part of the potential problem. Pilots are taught that when they get in trouble, such as accidentally flying into a cloud and losing sight of land, they should communicate, confess, and comply, i.e., immediately communicate the problem to air traffic control; confess the details of the problem and risks being faced; and then comply with the instructions they receive for a safe recovery. In addition, as soon as awareness of the incident communicated, the user(s)/investigators must immediately begin to document EVERY aspect of the incident with time-stamped photos, videos, and/or typed, written, or audio notes. Protect patient(s) and patient identity. Protect staff and bystanders. Protect environment. Notify Senior Management with respect to disaster/risk/PR/ legal counsel. Identify institutional PR liaison(s), qualified and authorized to speak to press, family, staff.
646 SECTION | 9 Management of digital healthcare, information systems, and health informatics innovations
FIG. 2 Diagram of devices, actors, and information flow in modern accident investigations of ICT-connected medical products.
Identify internal or external lead investigator who is qualified and authorized to investigate and document sensitive systems and information. Protect and preserve evidence. Ensure patient, other persons, and environment are all clearly documented and timestamped with notes, photos, or other means. Disconnect from networks and Internet and all other devices. Trace and document all interconnected and interdependent systems immediately. Must identify if other devices/systems/subsystems may be compromised. If so each such system/subsystem may need to go through this entire set of procedures immediately and simultaneously. Hibernate device(s) if operating system (OS) allows. In Windows OS, the "hibernate" mode preserves all current settings and activities. Shutdown or restart will likely clear and reset everything, and possibly destroy most or all prior data. ALSO, shutdown or restart COULD trigger OS, antivirus, software, and even firmware updates, any or all of which could destroy critical evidence. Disconnect device(s) from alternating current (AC) power. However, this can only be done if the device is in a hibernation mode. Otherwise, unplugging from AC power runs the risk of an abrupt forced shutdown and cold/hard restart, again risking loss of all prior data and settings. Carefully consider removing battery/batteries, only if evidence/data will not be put at risk. Document the entire environment. Do not repower or reconnect anything!
Document externally, via examination or from computerized maintenance management system (CMMS) details such as system/subsystem/device serial numbers (SNs), revision levels, passwords, configuration specifics, interoperability capabilities and connections, customization info. Diagramming may help. Develop a few failure mode and effects analysis (FMEA) fishbone diagrams, brainstorming potential causes, gaps, considerations, risks. Develop forensic analysis toolkit needs, options. May need HIPAA audit logs, network access logs, UserID role authorization details, device/system/environment change and/or update authorizations and logs. Consider non-destructive cloning of hard drives and any preserved flash memory on the device.
Summary This chapter is an initial exploration of how to extend past problem, accident, and forensic reporting and analysis methods when computerized technologies are involved. Merely sequestering an individual medical device will not likely provide sufficient information about the environment and/or user interactions with the patient and/or device, because many other software and hardware components and systems may have an interdependent role in safe operation and outcomes. Readers who intend to explore these challenges more closely may be well advised to obtain the latest copy of the free NIST Security Incident Handling Guide (https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/ final) and the free NIST Contingency Planning Guide for
Forensics and accident/incident investigations Chapter | 88 647
Federal Information Systems (https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final). These NIST and other related free NIST Special Publications can be invaluable resources for clinical engineers and forensics investigators who are preparing to support the growing complexity of interoperable ICT and medical device systems. (https://csrc. nist.gov/publications/sp).
Reference Hansel, B.C., 2008. Risk Versus Liability: Managing Device Incident Reports. Biomed. Instrument. Technol. 2008, 42 (1), 61–63. https:// doi.org/10.2345/0899-8205(2008)42[61:RVLMDI]2.0.CO;2. and https://www.sfda.gov.sa/en/medicaldevices/gcc/Workshops/ Documents/1DeviceAccidents_RecognitionandInvestigationProcess_ SFDA.pdf.