ISSA DEVELOPING AND CONNECTING CYBERSECURITY LEADERS GLOBALLYSecuring Medical Devices

While Maintaining FDA Compliance Securing

Medical Devices While Maintaining FDA Compliance

24 – ISSA Journal | May 2014

The information technology (IT) team responsible for vulnerability and patch management runs a scan and finds numerous systems that have vulnerabilities with

CVEs dating back to 1997. Following protocol, the results are fed over to the patch team who realizes that the systems are not showing in their asset inventory and subsequently send the vulnerable systems list over to the clinical engineer-ing (CE) team—sometimes called biomedical engineering (Biomed)—responsible for the management of patient care systems. The CE team responds back with an acknowledge-ment of the issue and re-states that the systems are exempt from IT’s patch management program because—as the ven-dor has stated—patching them will break Food and Drug Ad-ministration (FDA) compliance. At this point, the IT team is instructed to back down, extend the exemption for these systems, and wait to re-address it in the future as it is a known issue and management has signed off on it. This is where the issue usually ends, and therefore, is where we begin.

Since 19691 patient care or “clinical” systems were managed by teams with electrical engineering backgrounds, as they needed to manage electrical connections, switches, servo motors, and other physical electronic components to systems such as dialysis machines, ventilators, and lighting. In the last ten years, more medical devices have been connected to the hospital’s IT network, which has blurred the lines between the responsibilities of management of IT systems compared to clinical engineering or Biomed systems.2 This increase of connected medical devices has also led to increases in cyber-security attacks3 on these patient care systems, resulting in a new set of challenges as these teams operate based on histori-cal differences and operating off of different playbooks, both trying to secure patient care systems while maintaining FDA compliance. In this article, we focus on understanding the gap in percep-tions versus reality for securing patient care systems, what

1 http://en.wikipedia.org/wiki/Clinical_engineering - History.2 http://forecasting.tstc.edu/techbriefs/biomedical-equipment-information-systems/.3 http://online.wsj.com/news/articles/SB100014241278873241886045785431627449

43762.

This article focuses on understanding the gap in perceptions versus reality for securing patient care systems, what changes can be made, and how to go about sharing this information to drive positive change at healthcare providers, device manufacturers, and for organizations who support or maintain these patient care systems.

By Jonathan (J.J.) Thompson – ISSA member Silicon Valley and Central Indiana, USA Chapters

Good intention but a dangerous cycle of misunderstandingIn my experience, overall misconception that medical de-vices cannot be securely managed without breaking FDA compliance has led to significant issues impacting patient care, which have been noted first hand during security as-sessments at healthcare providers. In one example, a data analysis revealed that there were a few persistent issues with a cardiac system used in an operating room due to the ad-ministrator account being locked out, requiring manual in-tervention by CE team members. The root cause was malware that was causing the failed login count to trigger, locking out the administrator account. The result of the lockout was that the procedure had to be paused—with a patient open on the table—until the account was reset and the procedure could be continued. While a delay of 15-30 minutes does not sound like much to the average IT staff member, anesthesiologists and cardiac surgeons would disagree, as exceeding the rec-ommended dose (which is based on duration and volume needed to accomplish the sedated state during a procedure) leads to negative outcomes.7 After further analysis of these issues, the root cause tended to be due to miscommunication of FDA guidelines between IT, clinical engineering, and the vendor sales representative. IT views the issue the same as they view patching of non-clinical systems. To them a system is a system, and one really is not different from the next. This perspective can be deadly when coupled with pushing patches en masse to a combi-nation of clinical and traditional IT systems, as the patches may cause a Class 3 device to stop working or reboot mid-procedure. The challenge is that with IT running a mature or maturing patch and vulnerability management program, they do not tend to see eye to eye with the clinical engineer-ing team that treats patching and securing patient care sys-tems as blasphemous. IT simply wants to manage all assets of

7 http://cdn.intechopen.com/pdfs-wm/30196.pdf.

changes can be made, and how to go about sharing this in-formation to drive positive change at health care providers, device manufacturers, and for organizations who support or maintain these patient care systems.

Partially quantified, fully misunderstoodModern medical and diagnostic equipment, such as imaging systems, ventilators, surgical support devices, and cardiac monitors found throughout facilities and hospitals, are net-worked and vulnerable to intentional and unintentional cy-berattack through viruses and malware. In the field, we have seen these problems not only cause the equipment to slow down or reboot, but they can increase the procedure time dramatically due to misconfigurations and availability issues during surgery.

“Over the last year, we’ve seen an uptick that has increased our concern,” said William H. Maisel, chief scientist at the FDA’s Center for Devices and Radiological Health. “The type and breadth of incidents has increased.” He said offi-cials used to hear about problems only once or twice a year, but “now we’re hearing about them weekly or monthly.”4

While aware of this concern, healthcare teams responsible for the maintenance of these systems often do not take steps to secure patient care systems due to concerns that their activi-ties would violate FDA compliance. These resultant known vulnerabilities expose patients relying on these medical de-vices to heightened risk of complications and can increase legal risk exposure to healthcare providers as these issues are known issues, with proposed options from the FDA5 that have been reported publicly.6

4 http://www.washingtonpost.com/national/health-science/facing-cybersecurity-threats-fda-tightens-medical-device-standards/2013/06/12/b79cc0fe-d370-11e2-b05f-3ea3f0e7bb5a_story.html.

5 http://www.fda.gov/MedicalDevices/Safety/MedSunMedicalProductSafetyNetwork/ucm127922.htm, March 2010.

6 http://www.washingtonpost.com/national/health-science/facing-cybersecurity-threats-fda-tightens-medical-device-standards/2013/06/12/b79cc0fe-d370-11e2-b05f-3ea3f0e7bb5a_story.html.

May 2014 | ISSA Journal – 25

Securing Medical Devices While Maintaining FDA Compliance | Jonathan (J.J.) Thompson

In a transcript of a presentation provided by the FDA in the wake of the confusion about patching and securing patient care systems, the FDA addresses the two key issues that have often plagued our clients. (1) The common challenge of clinical engineering team members receiving misleading information from their ac-count representative at a medical device manufacturer that it is against FDA compliance to patch or secure the operating system.

I’ve gotten calls from users and they’ve said they’ve called the device manufacturer and the device manufacturer says, “I can’t do anything; I have to get FDA approval.” So we went back and examined this question and the answer is that pre-market review of a software patch or a cyber-security update usually does not require FDA pre-market approval.There is a guidance…available on our website about when to submit a new 510 (k) or a new pre-market submission. The rules are basically still the same for cybersecurity patches as they are for other changes. One is if it does not change the intended use of a device, there’s no require-ment for pre-market submission. Two is that it doesn’t in-troduce any new elements of risk.Our opinion is that we can’t think of a case where a cyber-security patch would represent a change of intended use or the introduction of new risk. In fact we believe that this is a decrease of risk.

(2) The FDA requires medical devices to only be updated by the device manufacturer.

The other question I’m always asked is does the FDA reg-ulations prohibit a user from updating his own medical device? The answer to that question is no. I get phone calls all the times, from users, and they’re being pressured by their administrative staff or their executive staff to put this patch on. They want to defend themselves by putting the FDA flag up, saying, “Well the FDA says that I can’t do this.” Well there’s no regulation that prohibits a user from modifying a medical device.8

Overcoming the challenges The good news is that in the cases and issues noted above, the impact to patient care could have been avoided. Through my experiences in assessing, auditing, remediating, and provid-ing security operations services to over 50 healthcare facili-ties in the last few years, the following are the key steps that IT and executive leadership took to mitigate the risks of IT security issues impacting patient care.

1) Clinical engineering needs guidance and formality around the systems they manage, what level of FDA compliance is required, and how they can manage the devices programmatically

8 Cybersecurity for Networked Medical Devices Containing Off- the-Shelf (OTS) Software, John F. Murray Jr., Software Compliance Expert US Food and Drug Administration, http://www.fda.gov/MedicalDevices/Safety/MedSunMedicalProductSafetyNetwork/ucm127922.htm, March 2010.

the same operating system the same way. The myriad of “if, then” conditions leads them to step away and simply defer to the clinical team’s judgment. In effect, the IT team with the strong process for managing weaknesses in operating sys-tems is being overruled by claims of breaking FDA compli-ance by the clinical engineering team that tends to have no process in place. Clinical engineering teams responsible for managing patient care systems in healthcare facilities often express the desire to secure patient care systems, but they have been told by their

medical device vendors that this cannot be done. Historically, in their experiences, that is where the buck stops—with the vendor representative. Unfortunately, in my experience, medical de-vice vendors have claimed that modifying their systems through deployment of security practices such as patch and vulnerability management, hardening, and de-

ployment of other security controls is a software or firmware change that would result in new issues of safety and efficacy. Therefore, the vendor claims the device would be out of FDA compliance until a new 510 (k) is filed. This has led those re-sponsible for maintaining the availability of these patient care systems to push back against IT or security teams to obtain exemptions to key controls in the name of FDA compliance, and the exemption is usually granted. Clinical engineering is being errantly guided by their vendor sales representatives. Sales representatives or account managers at device manu-facturers likely do not understand how the security issues impact the effectiveness of the device and or have been mis-guided internally due to emphasis on maintenance contracts and simplifying support of those devices by influencing as few changes to the device’s underlying operating system as possible—all under the flag of FDA compliance. This results in responding to security inquiries by clinical engineering staff (or written into contracts) that only vendor patches may be released and applied by the vendor. This has led CE teams to push back on IT to avoid standard security practices like patch and vulnerability management, security hardening, and antivirus/anti-malware on the medical device systems (such as the Windows box that runs a ventilator, an MRI, or a surgical robot). Unfortunately, this results in not only exposing patients to significant risks, but it is not the intent of the FDA guidance.

Clearly communicated, failing operating effectivenessIn the past few years, the FDA has issued clear commentary to clarify that they want patient care systems to be secured and for healthcare systems and manufacturers to cooperate with the FDA and healthcare providers to see to it that patient care systems are safe and secure.

Clinical engineering is being errantly guided by their vendor sales representatives.

26 – ISSA Journal | May 2014

Securing Medical Devices While Maintaining FDA Compliance | Jonathan (J.J.) Thompson

After speaking with clinical engineering staff at several loca-tions, they believed the configuration of devices could not be altered due to FDA certification requirements. Further, when asked, none could identify which devices were FDA certified and which were not. Finally, none of the clinical engineering groups reported that they were following a change or config-uration management program with any acceptance or testing criteria. A few groups did report they were scheduling pre-ventive maintenance at least annually. These problems must be addressed if healthcare facilities are to secure their devices and protect patients from cyberattack.

2) Identify constraints, determine controls and guidelines, and manage clinical systems risks Clinical engineering/Biomed consistently claimed that they could not touch their systems to better secure or patch them due to FDA constraints, which appears to have resulted in in-formation technology and security teams shifting away from holding clinical systems owners accountable to how clinical systems are secured. Upon further discussion, it was deter-mined that systems could be placed into buckets with variable levels of modification based on both FDA and vendor con-straints. The challenge is that it would require a significant amount of effort for individuals managing clinical systems to stay on top of what can or cannot be modified, based on those constraints, especially given the challenges with asset tracking, inventory, and patch management for non-standard systems. Upon conclusion of discussions, CE at each location agreed that there needs to be (1) defined categories of clini-cal systems, (2) standards and guidelines for each category, (3) a way to identify the systems in the system name or by other means, (4) a process to determine when patches can be added to the systems, and (5) a documented list of what can or cannot be modified on the system to eliminate the need to contact the vendor before any/all changes to the system. Further, procurement and legal should identify key language that goes into contracts with device manufacturers to clearly differentiate handling protocols for the clinical engineering and IT teams for patient care systems PRIOR to contracting and deploying. Attempts to add this clarification on the back-end of the deal tend to fail as the vendor sales representatives are usually no longer incentivized to put effort into the deal once it has closed.

3) Identify the buckets of clinical systemsAppoint a person or team from the clinical engineering staff with the responsibility to research and track all devices for FDA compliance requirements and associated vendor patch availability as well as local configuration management. From this research, develop and implement buckets, or categories, that each system falls into with regards to the ability of the purchaser to alter the device’s configuration. For example, unlike other software, many patches for medical devices can only be installed by an approved technician per the manufac-turer’s support agreement. This means, for example, that in the case of Philips XPER devices, a Philips technician must travel to each facility the device is used and update the device

When I need custom answers, Wisegate digs in to get me what I need. It's a safe place to share my expertise and gain insights from others.

Expert-Sourced IT Network — On Demand

• Direct line to vetted, senior IT professionals

• Cost-effective advice

• Faster, instantly actionable answers

• Personalized, unbiased research

• Customized to your project, industry, role, and more

www.wisegateit.com

A Gated BRAINTRUST ofthe Wisest in IT

Bill BurnsISSA MEMBER & CISO EXECUTIVE ADVISORY COMMITTEE

May 2014 | ISSA Journal – 27

Securing Medical Devices While Maintaining FDA Compliance | Jonathan (J.J.) Thompson

that conflict with maintenance contractual provisions are be-ing made regularly (such as unintentionally updating patch-es on a clinical system that was mixed in with non-clinical systems in the patch management tool). Facilities use vastly different systems, from Excel spreadsheets to other programs like Medimizer, and often times even within the same health-care system these asset management systems are disparate. In looking at asset management or change management da-tabase records at client sites, it became clear that some asset data fields get added to the management systems, but often containing inaccuracies which were identified through in-quiry-based periodic system survey processes utilized dur-ing pre-assessments. Clinical systems do not have a control (naming convention, restricted domain admin access, etc.) that allows the help desk to know when they should or should not follow end user requests for enabling certain features on the operating systems. Breaking vendor maintenance agreement compliance could be as simple as an end user nurse calling the help desk to ask them to install Internet Explorer on “her” system, providing the asset tag information (which does not identify the asset as a clinical asset), the help desk assisting with the Internet Ex-plorer install, and the user then proceeding to use the newly

manually.9 This also leads to post-purchase issues if legal is not involved in adding in service level agreements (SLAs) to ensure that the vendor is contractually obligated to perform patching and security updates in a pre-defined amount of time. Develop a standard operating procedure (SOP) akin to each bucket and label each device in accordance to its bucket membership. Provide extensive training to CE and MIS/TSM staff on the buckets, SOPs, and expectations for system build and patch and configuration management.

(1) Do not touch—Ever (2) Pre-approved for AV and patching(3) Pre-approved for AV OR patching, within certain con-

straints(4) Vendor patches only(5) Full control of patching and security controls 

4) Improve asset management for clinical systems Clinical systems are inconsistently tracked and managed, in some cases already breaking vendor compliance as changes

9 Billy Rios, Pushing Medical Device Security Forward, ISSA Journal, July 2013.

The CurmudgeonHEALTH CARE. GREAT. We have to apply to Obamacare (Afford-able Care Act) and if we don’t, we get fined, every tax return. Hmm.

Now let’s check that program out.

Behind schedule? Check. Overpromised? Check. Doesn’t work? Ab-solutely Check! (According to the news, it’s all front end, nothing actually accomplished.) Looks good? Check. Politically acclaimed? Double check! Talk about a classic, textbook case of a monster soft-ware project driven by unrealizable expectations!

These are the folks that want you to “trust them” with all your med-ical (and financial and personal) information, which SHALL be in digital form, and they’ll get back to you about all those vulnerabili-ties, lack of availability, failure to meet schedule, and so on. Trust ‘em. They know what they’re doing.

Since this is the Government, there couldn’t be anything wrong with tying your tax information to your medical program sign-up to your medical records to your online activities to your political views to.... They demand and require that we “trust” them and that they will “protect” our information.

Kinda like those large corporations that demand the same. Let’s just check their track record, shall we? Just how much have they protected our info? (Target? IRS? NSA? Local governments?)

The physician’s assistant updates the records, and minutes later, the doctor shows up with that information, but nobody jacked in. Oooh. Wow. What could possibly go wrong with WEP or WPA2 for encryption of the important links? Or, wait! Could they possibly use SSL? Which version?

The doctor uses a “laptop” or “tablet,” presents prescriptions quickly after tapping on the screen, without having physically con-nected to the printer.

So, someone finds herself in the hospital. She “might possibly” want to know that there is more malware on medical devices than on the doctors’ laptops! Great. Your heart monitor is mining Bit-coins in its spare time, and it has a lot of spare time these days. Your blood monitor is sending spam in its spare time. Your drug doses are bar-coded, scanned, and authorized by a red or green LED on the scanner, as compared to the database the hospital or wherever maintains. By the lowest bidder.

Hmm, how may I ‘sploit your RFID? “Let me count the ways!”

Shall I put the SQL injection attack on the RFID? “ ‘ OR 1=1; DROP ALL TABLES;’”

Or, perhaps, I should confirm massive insulin injections for some-one? Application of anti-coagulants, particularly if that patient has any hemophiliac tendencies. Anaphylactic-shock allergic to nuts, particularly peanuts? GREAT! Lemme prescribe you a PB&J for lunch. Onions? So, want some “Mongolian” Beef or something? Maybe garlic extract?

So, how could this data possibly be used in the insurance industry? Life, Health? Anybody? Medical insurance? Dental? Visual? Long-term care? How could that possibly affect anyone’s premiums?

So, did you eat your veggies for tonight? Did you log that into your medical insurance providers? Your doctors? Dentists?

Oy, and now, we have DNA screening and typing. On an individual basis.

Like C-4 and nails: “This will not end well!”

Your local, grumpy, tie-wearing, un-impressed Curmudgeon

28 – ISSA Journal | May 2014

Securing Medical Devices While Maintaining FDA Compliance | Jonathan (J.J.) Thompson

installed Internet Explorer to introduce malware onto the controller system by browsing the web during a break. Facilities should determine what processes and enablers (such as databases, spreadsheets, or other tools) will be utilized to identify, track, and manage clinical systems. This should then be consistently followed. Controls should be implemented to verify compliance with these protocols. Further, clinical sys-tems should have a set name that will identify the system as a clinical system (such as in the NetBios name with a clinical prefix such as “CE”-12049 instead of just the asset reference number), even when technical support is helping an end user. The help desk could also be prevented from having permis-sions to work on clinical systems in those domains.

5) Create a list of indicators of patient care issues I have found that there are usually indicators and patterns that can be reviewed through data analytics to discover if patient care is being impacted by clinical systems issues. For instance, review internal outcome statistics to identify situations where patients were under anesthesia longer than anticipated by some percentage. As described earlier, issues with an administrator account being locked out on some car-diac monitors used during open heart surgery were caused by malware existing on the unprotected Windows control-ler system. The recorded patient surgical outcomes indicated that the patients were under anesthesia longer than the tar-geted window. This simply illustrates that there are indicators and data that can be analyzed, which will sometimes lead to a root cause that can be mitigated by securing these clinical systems. It’s not every day that IT security can be in a position to save lives. I hope this encourages you to try to identify data points that you can analyze in your environment from which you could potentially change patient outcomes for the better.

6) Address fears proactively and offer solutions based on FDA precedentWhen McAfee released an automated update of its virus definition files, the antivirus product incorrectly flagged a critical piece of Windows software as malicious—and quar-antined the software.10 This disruption of a critical file caused a number of hospitals to suffer downtime. Medical systems were rendered unavailable. This is the extreme case that sticks in the mind of healthcare executives and drives analysis pa-ralysis when it comes to taking on the battle to challenge the status quo when it comes to pro-actively securing medical devices. Before bringing the tactical challenges and solutions to senior leadership, make sure that you are prepared to ad-dress not just the technical aspects of your proposal but also the emotional and fear-based thoughts that linger from sto-ries where security was not the solution but was instead the problem. Make sure that before you address these challenging issues internally or with your vendors, you are armed with the FDA

10 John Leyden. Rogue McAfee Update Strikes Police, Hospitals and Intel, http://www.theregister.co.uk/2010/04/22/mcafee_false_positive_analysis/, April 22 2010.

EDITOR@ISSA.ORG  •  WWW.ISSA.ORG

For theme descriptions, visit www.issa.org/?CallforArticles.

ISSA Journal 2014 CalendarPast Issues – click the download link:

You are invited to share your expertise with the association and submit an article. Published authors are eligible for

CPE credits from organizations such as (ISC)2.

JANUARY Cyber Security and Compliance

FEBRUARYRisk, Threats, and Vulnerabilities

MARCH Legal / Privacy / Ethics

APRILSecurity and Cloud Computing

MAY Healthcare Threats and Controls

JUNE Identity Management

Articles Due: 5/12/14 JULY

Practical Use of InfoSec Tools Articles Due: 6/1/14

AUGUST Big Data: Use and Security Ramifications

Articles Due: 7/1/14 SEPTEMBER

History of Information SecurityArticles Due: 8/1/14

OCTOBER Data Protection Strategies and Controls

Articles Due: 9/1/14 NOVEMBER

Cyber Security / Cyber DefenseArticles Due: 10/1/14

DECEMBER Best of 2014

PAST ISSUSES Cyber Security and Compliance

Risk, Threats, and Vulnerabilities Legal / Privacy / Ethics

Security and Cloud Computing

May 2014 | ISSA Journal – 29

Securing Medical Devices While Maintaining FDA Compliance | Jonathan (J.J.) Thompson

510 (k) process submission decision tree (specifically Flow-chart B).11 This is how you go through the key elements the FDA uses to determine if a new 510 (k) needs to be submitted. In short, if your scenario falls into the same category as this example from a publicly available DRYPIX 4000 Medical Dry Laser Imager analysis conducted by a regulatory coordinator (see table 1 and figure 1),12 the vendor will not have grounds to push back on your security improvement, as it would not require a resubmission.

Part I. Product Information/Description of Change

Product: DRYPIX 4000 Medical Dry Laser Imager

Comments:

The modification consists of technology and/or performance changes. Based on this evaluation, it appears that these changes (1) do not affect indications for use, (2) do not re-quire clinical data to evaluate safety and effectiveness, and (3) do not raise new issues of safety and effectiveness…Therefore, I have reached a conclusion that the DRYPIX 4000 represents a modification that does not require a 510 (k) sub-mittal. — Regulatory Coordinator

Table 1 – DRYPIX 4000 Medical Dry Laser Imager analysis

ConclusionWhile the FDA has issued guidance opinions indicating that vendors and system manufacturers have a responsibility to upgrade or patch vulnerabilities to cyberattack, this often has caused problems in clinical engineering departments at

11 http://www.fda.gov/ucm/groups/fdagov-public/@fdagov-meddev-gen/documents/document/ucm080243.pdf. See page 30 for decision tree.

12 http://www.umgxray.com/pdf/fujifilmdrypix4000modification.pdf.

healthcare facilities. Those departments should know which systems can be se-cured in-house and which cannot. This ensures these systems remain in compli-ance with FDA guidelines for cybersecu-rity. Challenges do exist in communicat-ing and understanding the demarcation points in responsibility for maintaining and avoiding breaching 510 (k) compli-ance by internal IT and clinical teams. In order to effectively overcome these challenges, key steps must be followed to quantify the challenge and provide guid-ance on how to manage it, and controls need to be put in place to maintain on-going effectiveness. Clinical engineering must do as follows: (1) define categories of clinical systems, (2) establish standards and guidelines for each category, (3) es-

tablish a way to identify the systems by a standard name or other means, (4) create a process to determine when patches can be added to the systems, and (5) create a documented list of

what systems can or cannot be modified in-house to elimi-nate the need to contact the vendor before any changes are made to the system. Taking these steps will move facilities closer to better security from cyberattacks and patient harm.

About the AuthorJ.J. Thompson is the CEO and managing di-rector of Rook Security, an IT security firm providing security strategy, crisis manage-ment, and next generation security opera-tions services. J.J. has been published in major industry jour-nals and covered in Bloomberg, USA Today, Forbes, CSO and other major media outlets. Currently he is serving as president of (ISC)2 Indianapolis, and is a former president of the ISSA Silicon Valley Chapter. He has has a degree in management sciences and may be reached at jj@rookconsulting.com.

Software or FirmwareChange?

A ect indicationsfor use?

Are clinical datanecessary to

evaluate S&E forpurpose of

substantial equivalence?

Do results of design validation raise new

issues of S&E?

Document analysisand �le

Submitnew 510(k)

YES

YES

YES

YESNO

NO

NO

NO

NO

B8

Change inpackaging?B9

NO

Change insterilization?B10

NO

B8.3

B8.2

B8.1

Flowcart B Is it a technology or

performance change?

(partial highlight)

Figure 1 – Flowcart B - focusing on software or firmware change (partial)

Collaborate. Discuss. Share.

ISSA Special Interest Groups connect people who are interested in a specific topic and would like to share resources. Special interest groups meet virtually

and non-members are welcome. Check out http://www.issa.org/?page=SIGs and plug into the Security Aware-ness, Women in Security, or Healthcare Special Interest Groups.

Join a Group today!

30 – ISSA Journal | May 2014

Securing Medical Devices While Maintaining FDA Compliance | Jonathan (J.J.) Thompson