Essential Software Documentation for Med Device Manufacturers | Ep. 21

In this episode of the Med Device Cyber Podcast, hosts Trevor Slattery and Christian Espinosa of Blue Goat Cyber delve into the critical, yet often neglected, topic of software documentation for medical devices. They argue that while cybersecurity is gaining attention in the product development lifecycle, the foundational software documentation required for both regulatory submissions and effective security implementation frequently lags behind. The discussion highlights a common scenario where manufacturers approach their FDA submission deadline (for a 510(k), PMA, etc.) only to realize they lack the necessary documents, such as a System Requirements Specification (SRS) or a comprehensive data flow diagram, which are essential for creating the required cybersecurity artifacts. The hosts frame the conversation around the international standard IEC 62304, which outlines the software development lifecycle processes for medical devices. They explain that the standard's documentation requirements scale with the device's complexity and risk classification. A high-risk, Class III implantable device like a pacemaker will demand far more rigorous documentation than a lower-risk Class II device. Slattery and Espinosa emphasize that this documentation is not merely a bureaucratic hurdle for the FDA but a cornerstone of good engineering practice. It ensures the device is maintainable, traceable, and understandable to new developers or team members. They share anecdotes of clients lacking even basic diagrams, which complicates the entire development and security assessment process. The main argument presented is that robust documentation practices must be integrated from the very beginning of the development process. Key documents they identify as top priority include the SRS (detailing functional and non-functional requirements), architectural diagrams, and data flow diagrams (which the FDA also terms the "global system view"). They stress the importance of documenting everything, including physical ports or wireless interfaces that are disabled, as undocumented components can introduce unforeseen risks and cause confusion for both security assessors and end-users. Ultimately, they conclude that thorough documentation is indispensable for building a secure and high-quality medical device, making the regulatory journey smoother and the final product safer for patients.

Trevor: Hello and welcome to another episode of the Med Device Cyber Podcast. I'm joined here today by Christian Espinosa. How are you doing today, Christian? Christian: I'm doing well. What are we talking about today, Trevor? Trevor: Today we're talking about something that blends well into cybersecurity, but people kind of see it as a little bit of a different topic, and that's going to be software documentation. Christian: Okay, so we're focused on medical device software development, the documentation required, what some of the best practices are, and how that ties into cybersecurity and how it pertains to a class two or class three device, you know, the the different complexities of the device, uh, affect the required documentation and also this ties into IEC 62304, right? Trevor: Yep, exactly. And an issue that we run into all the time is when it's time for a 510(k) or a PMA or a De Novo or whatever submission into the FDA, manufacturers weren't really getting ready for it. Even if they get ready for their, you know, they try to account for their cybersecurity early in the process. They still have six months out before their submission. They don't have any of the software documents that are required to translate into these cybersecurity documents. So, we want to talk about what some of the important documents to prioritize are. I'd say, you know, like the main five or six documents that should be top priority and then how that can vary depending on the device, sort of like you were mentioning. Christian: So these documents are really required from a secure product development framework perspective or DevSecOps. And then also without these documents, it's hard for us to do our job from a cybersecurity perspective because I know we've had several clients come to us that they didn't even have like a data flow diagram. I'm not sure how they developed their software without any documentation. Trevor: Yeah, I can think of times spent in Zoom calls where we're actively creating the documents and they're saying, 'Do you think the device does this?' or 'How should I word this best?' and so, it's it's not even just like a FDA issue or a cybersecurity issue. You want to have all this documentation ready so that, you know, you don't know who's going to be maintaining that code in the future. You don't know if you have a new hire, you don't want to spend months trying to explain how this product works. They just want to be able to read the documentation and know. So it goes even past the complaint that we have as, you know, the cybersecurity team and branches more into just it's just good practice to have all this clear documentation for a product in general. But especially for a medical device where there can be pretty complex, there can be a lot that's going on, a lot of different connected parts, and so you don't want it to be unclear to a new developer or a new team member what's going on there. Christian: Yeah, so what are the what are some of these top pieces of documentation? Trevor: Well, I think we'll sort of go back to something I think you mentioned a little bit earlier, and that's IEC 62304. So, that is the golden standard for secure development of a medical device, and it's a pretty lengthy, you know, standard document. Uh, it goes into a lot of different information on what you should do for preparation and what documentation you should do, best practices for development, uh, integrating security into your development life cycle. But one very important thing that it mentions is documentation is going to scale a little bit based on the device's complexity. And complexity can mean two different things. So, the first thing we'll talk about is just complexity, meaning is it a small system or is it a big system with a lot of stuff going on? If you have a very big system, tons of different interconnected parts, it doesn't matter if it's a fairly low risk system, there's just going to be a lot more to document by nature of what the system is. And so in that regard, you're probably going to have a lot more documentation for this super complex analysis software that's running in the cloud with a whole bunch of agents deployed on workstations, even if it's just doing an analysis on trying to figure out if you have the common cold or something. Um, compared to a single focus device, like let's say a... intubator. That's a much more serious device, much more critical function, but it doesn't really do much. It keeps your airway open. That's all it does. So, the documentation on what's going on in that device is likely going to be a little bit more minimal, even though it's a more complex system. Now, inversely, that can also mean the scaling, I guess, uh, danger of the device. Something like a pacemaker, an implantable, a class three device, is going to require a little bit more documentation and a little bit more scrutiny into what's going on as opposed to something simple like an oxygen pump, a class two device with minimal risk to the patient. So, now that I've given that long-winded preamble into some of the important documentation, it depends on what we're doing there, but I think the first thing that is going to be super important is a requirement. So, a requirement is, there are two types of requirements. The first is a functional requirement, what does it do? The next is a non-functional requirement, how does it do it? So, we'll go to the intubator example. One of the functional requirements is can hold a throat open or doesn't, you know, collapse under pressure, something like that. And then the non-functional requirements, oh, it should be a soft material so it doesn't scratch the patient. Or, you know, if you have some fancy kind of device with all sorts of cool functionality, you might have individual requirements based on what that does. Maybe it has some AI-enabled functionality where it determines the cause of why the patient's throat was closing. Um, but getting those requirements written down outside of just knowing, 'Oh yeah, this is what we want it to do.' You want to have it written down, you want to have a way to verify it's in place. And that's a requirement specification. I think that's probably going to be one of the most important documents to create, no matter what the device is, no matter what it does, is just having a list of what does it need to do. This is the SRS. Christian: The system requirement specification. Trevor: Yeah. Yeah. And it can go a little bit deeper than that as well, outside of the SRS. You need to have test cases to determine that each requirement is in place and works. So, you know, a test case for seeing if something has soft plastic to not scratch a patient, you can really just feel the device, see if it is scratchy or see if it's actually soft. For pure software, that can be a little bit different. Um, like a login page can often have some easy examples here. You can say the functional requirement is it takes a username and password. You test it, put in a username, put in a password, does it work? Great. A non-functional requirement is it's escaping bad characters. And that's also a security requirement, which is something that the FDA is really looking for in cybersecurity. Um, and so you test that by putting a whole bunch of bad characters that shouldn't be allowed in a username in there and seeing if the application rejects it, or if it lets you through and then you potentially have a vulnerability there. So, that's, in my opinion, one of the more important documents that you can have. I'd be curious to hear your thoughts, Christian, on some other important documents in this process. Christian: I like to see data flow diagrams and how all the data goes throughout the system and how an operator interacts with the data. Uh, those are my favorite diagrams because I think a lot of people don't really understand where the data goes and where it's stored and what format it comes out on. And we're doing when we're doing things like interoperability, it's important to understand the entire flow of the data through the system and what format it's in and how it's stored because the data flow diagram should should articulate that as well. Trevor: Yeah, I totally agree. And it's also an FDA requirement to have one available. It's the, they call it the global system view. And it's, you know, everything in the end-to-end system, you have to have a neat little diagram to show what's going on there. Christian: Yeah, I used to do a lot of network engineering and penetration testing of environments, and I was always surprised how many people or lack of people actually had an up-to-date network diagram of their environment. It's almost zero. I think one organization had one and they're super small, but I'm like if you don't know what's on your environment, how are you going to defend it? It's kind of the same thing with your system. If you don't know what, where the data is stored and how it's transferred back and forth to different subcomponents, how are you going to defend your data or make sure that your system is not hacked into? Trevor: It can become a really big risk with uh like having a proper network diagram too because, you know, someone brings in a printer or a phone or something, connects it to the internet and just leaves it there and forgets about it. That's an undocumented object in the network that is getting it potentially has problems, potentially introduces risk into the system and it's not documented. So nobody knows it's there to put controls around it. Yeah, I think, you know, hospital networks are always hostile networks as we like to say. But even in a medical device context, uh, we've we've dealt with a few devices before where we get a data flow diagram or an architecture diagram and it's, you know, part of our preparation for the penetration test, we need to know what what tools we need and you know, some of the stuff is kind of bulky. You don't want to just bring everything and, you know, hope you have what you need. You want to prepare for it in advance. And then we get the device and we look at it and we go, hey, there are a bunch of ports that weren't in the data flow diagram here. They go, 'Oh, well we didn't think it was relevant because they're disabled.' We go, no, it still has to be there. If it's a part of the device, it should be documented. Christian: So, it's like a rogue component. It's not documented, it's not necessarily known. Trevor: And it isn't an It's also a requirement to provide a data flow diagram as part of the labeling or an architecture diagram as part of the labeling for a device. And so you can imagine what is a user of the product going to think if they say, okay, let's take a look at what should go into this. They see all the different components, they see all the interfaces, and they see it should have wifi and a USB port and then they open it up and it has ethernet and an HDMI port as well. They're going to be confused about what's going on, why it's there. Did they get the right device? So... Christian: having a clear understanding of what goes into a data flow diagram is important as well. So even if uh the ethernet in this scenario you gave was disabled, we would want to list it on a data flow diagram. Trevor: You should and it should be listed as an inactive interface. It's not something that, you know, there's no data transfer, there's no purpose for it. But let's say you're just buying a motherboard which has that by default. You don't want to get a motherboard without it for whatever reason. That's fine. As long as it's disabled, but you can't just say, oh well, it doesn't do anything, so let's sweep it under the rug and forget about it. You still have to document it. You have to document the controls around it. This is disabled. Here's how we know it's disabled. We've proven this. That's why it doesn't introduce any risk, but it's still here as an inactive interface. So you should be aware that it is here if for no other reason just to know not to use it. Imagine, you know, it's not documented and the customer says, 'Oh, well there's ethernet, I don't want to use Wi-Fi.' and then they sit there and fight with it for three hours trying to figure out what's wrong. Christian: Yeah, that's a good point. And uh something we test is that negative testing, I guess like you said, to make sure if there is an ethernet interface or a USB port and it's supposed to be disabled that it actually is disabled. I think we've had a few clients tell us that Bluetooth Low Emissions or BLE was disabled but it actually was not. Is that, is that am I remembering that right? Trevor: Yeah, we've had that with Bluetooth, we've had that with Wi-Fi. Um I'm trying to think if we've had that with any other interfaces. I believe we've actually even had that with uh 5G before which was kind of interesting. either 5G or 4G. But it can be pretty easy. A lot of these components that, you know, these off the shelf components that manufacturers are using, it already has, you know, Wi-Fi, Bluetooth, whatever, built into it. And the manufacturer doesn't need it. They just use that component for something else, but they put it into the device, start it up, and then there's a Bluetooth connection to interact with the product somehow. Or there's a Wi-Fi connection, it can connect to an access point and then it can be visible to anything on that network. And manufacturers just aren't really, you know, maybe they're not aware or they're not conscious of that functionality or they don't think it's as big of a deal as it could be. So yeah, it's a really important point when we're doing these tests, we have to make sure that everything is disabled as well as ensuring the security of what's enabled. Christian: Is there any regulation beside or standard besides 62304 that makes sense for a Medical Device Manufacturer to follow when they're developing software? Trevor: Well, I think this will this sort of leads into another interesting point. I feel like medical device development has a couple of different facets. Um of course the software documentation, the device documentation, developing it securely is important, but all of the SOPs, the standard operating procedures, and the policies around a device or around an organization go hand in hand with it. And when we're going through the FDA submission process, we need both of those to make sure that we're covering everything. We need to know what is the company doing, what is the device doing? So that leads us right into ISO 13485 which is about quality systems and medical devices and the regulatory documentation that you need to have. So it covers stuff about how's your risk management process work, what's your standard operating procedure for handling um updates in the device, What's your corrective and preventative action procedure? All of that gets covered in a mature quality system. So I think developing those two areas side by side are really important. Christian: How how do those areas get developed side by side? Because I I I've worked with a lot of software developers. We have quite a few that are partners and it seems like they typically say they're ISO 13485 certified, not uh IEC 62304. And I I was I was wondering like why that is. Trevor: So, IEC first off, IEC 6 C 62304 is a bit more of a global standard. Um, it's used by the MDR, it's used by the FDA. Uh, it's a little bit more on the MDR side, it's still very applicable to FDA concerns. Whereas ISO 6 or 13485, oh man, a lot of numbers. It's uh a little bit more targeted on the FDA side, but again, it's still applicable elsewhere. So manufacturers that we interact with, we're an American company, we interact with a lot of American companies, they're going to look more at the American regulations. Um, but it's more than just, you know, the development practice, it's the quality practice. So how are you ensuring that you're designing a safe device, you're designing quality documentation, to understand that you have the requirement to build out all this software documentation as per 62304, you need to have the correct standard operating procedures, the correct risk management documentation, and everything that is developed off of 13485. So they blend together nicely. Um, where one is focused purely on like device descriptions, how are you designing security into a device, and the other is just general quality in a device. How are you, you know, dotting all of your I's and crossing all your T's? You have all the documentation that you need, you have the policies, you have that risk management approach. It's clear, it's repeatable, nothing is done ad hoc, everything is traceable. You have all of your design history files for your different documents. So they're a little bit of a they're a very connected process but still a little bit separate. Christian: It sounds like you're saying 62304 is more the process and 13485 defines how you manage all the documents that make up that process from a quality perspective and a traceability perspective. Trevor: Yeah. Yeah, and with the actual device development, they're just focused on slightly different things. So 62304 is designing a secure device which is what the FDA looks for, it's what all these different regulatory agencies look for. They want to see security built into the device. So it's essentially the guide of okay you want to sit down and start building your product, this is step one to make sure it's you're building it safely, this is step two and so on and so forth. Whereas 13485 is more sitting down and saying okay how can we make sure that we have repeatable processes, we're covering all of our documentation, everything is traceable, nothing slips through the cracks, we don't have problems where we're, we aren't documenting things that we should be. So they're both very important. They should be integrated at the early stages of a startup or device development. Um, they're just focused on more organizational things or more device-specific things. Christian: Cool. Well we're coming up here on time so, what's some parting words of wisdom for anyone that's looking at getting some software developed for medical devices or looking for best practices, would you say? Trevor: Make sure that your engineers are aware of what artifacts they need to prepare and more documentation is always better than less. If we start working with a client, they come to us with, you know, 5,000 pages of documentation, our job's going to be a lot easier than if they come to us with 10. Christian: But we know that software developers don't like documentation. Trevor: They don't and it's the same way as penetration testers always hate writing the reports. They just want to do the hacking. Software developers just want to do the coding. They don't want to say what they coded. And so you have to find someone who begrudgingly accepts their responsibility to write software documentation. Christian: Yeah. I mean, ultimately, the documentation matters in some cases more than the code itself, just like the report matters more than the, you know, great hack the penetration tester pulled off. Trevor: I think about some products that I've developed and code that I've written and I don't touch it for six months and then I come back and I'm just like, 'What idiot wrote this code? There's no way to understand what's happening here.' Christian: Awesome. Well, I hope everyone got some value out of this episode and be sure and tune in uh for next week. Uh we've moved to uh weekly episodes so we'll see you next week. Thanks.