Archive for the ‘FDA’ Category

Full Cycle Teams in a FDA regulated setting

Monday, January 4th, 2021

Full Cycle DevelopersThe 200X hot topic was Agile development in a FDA regulated setting. Over a decade later this should (hopefully) be a settled issue. I can’t imagine anyone still doing water-fall these days. The new challenge for medical device companies is implementing Full Cycle Teams (FCTs), which is well described in Full Cycle Developers at Netflix — Operate What You Build.

This organizational structure increases the speed of feature delivery and allows for experimentation to further improve the customer experience. Tooling and automation ("paved roads") are key. The model that Netflix came up with:

"Full cycle developers" is a model where a development team, equipped with amazing developer productivity tools, is responsible for the full software life cycle: design, development, test, deploy, operate, and support.

If you work for a large enough enterprise, you likely have teams of people that provide the following functions:

  • Product development (creates and designs applications software and includes architects, product owners, and scrum masters)
  • Quality assurance (QA). They test the software. For a medical device company, we call this team Verification and Validation (V&V)
  • Site Reliability Engineering (SRE). Ensures scalability and reliability of the infrastructure and applications. They do performance testing and may implement some Chaos engineering techniques.
  • Development operations (DevOps). Manage the code repositories, shared development tools, CI/CD pipelines, middleware, databases, etc.
  • Infrastructure management (on-prem hardware and operating systems)
  • Cloud management (same as above,  but in the cloud)
  • Applications support (monitor and manage applications in production)

Do not confuse FCTs with "Full Stack Teams" (see Full Stack Pronounced Dead). This "stack" refers to technologies that are used to implement a typical web-based application (e.g. LAMP).

FCTs are about supporting functionality end-to-end (product idea to production), but both have the challenge of developer specialization in common. A FCT has to broaden their skill-set even further to include application/infrastructure deployment, monitoring, and support. This is the future!

Full Cycle Team Challenges for Medical Device Companies

The transformation from a legacy organization (as described above) to FCTs is made even more challenging for a medical device company creating software that has to maintain FDA regulatory controls (see Quality System Regulation Subpart C–Design Control § 820.30).

Below is a list of regulatory and transition considerations that impact the release process. Most are associated with keeping the Design History File (DHF) documentation up-to-date. The organizational challenge in a FCT world is figuring out who is responsible for these tasks.

Spoiler alert: The suggested answers should be obvious, but many times the best I can do is just ask the question. Every organization, and even different teams within a single organization, will have different solutions. These can be tough problems to solve. Don't shoot the messenger!

Medical Device Data System (MDDS)

Not all of your software may be under FDA Class II/III regulatory controls. Some could fall under MDDS, see Identifying an MDDS. There is still some risk associated with MDDS but special controls and premarket approval -- the 510(k) -- are not necessary (see MDDS Rule).

MDDS software requires the same QMS documentation (see MDDS Section VI-E. Current Good Manufacturing Practices (CGMP)/QS Regulation/MDR Compliance of the rule) so most of the items listed here still apply.

Also, see Comment 25 from the rule which addresses "modular software". I.e mixing MDDS components with medical device components. The response says "The MDDS regulation does not necessarily prevent modular implementation.", but the FDA can't make a "generalized determination" on the various ways these combinations may be made. This may be a situation you run into and the FDA suggests it is best to contact them if you have questions.

Validation and Verification

General Principles of Software Validation; Final Guidance for Industry and FDA Staff (PDF)

Based on the intended use and the safety risk associated with the software to be developed, the software developer should determine the specific approach, the combination of techniques to be used, and the level of effort to be applied. While this guidance does not recommend any specific life cycle model or any specific technique or method, it does recommend that software validation and verification activities be conducted throughout the entire software life cycle.

FDA guidance documents, and FDA regulations in general (e.g. IEC 62304), tell you what to do, but leave the how up to the organization.  

Let's highlight the SRS* to System test verification from the V-model. This is essentially end-to-end testing. In a microservice-based architecture, each FCT is likely responsible for different sets of services. These services may be dependent on the services provided by other teams.

Which team is responsible for ensuring that the entire system is functioning properly (i.e. end-to-end test protocols and results) after changes are made to one or more of these services?

In an ideal world, these end-to-end tests are completely automated, but even then someone still needs to maintain them.

Validation testing (was the right product built?) presents even more challenges as a single FCT is may only be responsible for a small portion of the entire product.

Risk analysis

From Medical Device Design Risk Management Basic Principles:

Risk analysis is typically done by a cross-functional team that may span multiple business units, but it is probably not unreasonable for the FCT Product Owner to drive this process and get the documentation updated as needed.

Traceability

From the FDA guidance:

A source code traceability analysis is an important tool to verify that all code is linked to established specifications and established test procedures.

Creating this documentation is well suited for automation. It still requires ensuring that all requirements and related test scenarios are properly tagged so they can be parsed to produce a release report.

Software Design Evidence

From the FDA guidance:

The Quality System regulation requires that at least one formal design review be conducted during the device design process. However, it is recommended that multiple design reviews be conducted (e.g., at the end of each software life cycle activity, in preparation for proceeding to the next activity).

This is a challenge for any Agile-based development process so is not specific to the FCT-based organization. Running formal design reviews as early in the development process as possible should be a team responsibility.

Manual Approval Gates

For many unregulated software products continuous integration (CI) and continuous delivery (CD) is a reality. I.e. Code can be pushed, run through the CI/CD pipelines, and delivered to customers without human intervention.

It is very unlikely (not impossible though I suppose, depending on the product) that this would occur for FDA-regulated software. Even with automated document generation, software deployment to production will still require human sign-off steps and audit trails.

Off-The-Shelf (OTS) Software

OTS/SOUP Software Validation documentation needs to be kept up-to-date. This is mostly a book-keeping exercise for OTS/SOUP that is part of the software product. For tools though, see OTS/SOUP Software Validation Strategies.

Another consideration to keep in mind for including 3rd party software into your product is the software license. The corporate (legal) policy should dictate license requirements, but teams would be aided by an automated tracking process.

Infrastructure

Installation, operational, and performance qualification -- IQ/OQ/PQ. FDA regulated software must have these processes in place to ensure that after any changes are made, the infrastructure continues to meet quality requirements.  With the microservice architecture becoming a best practice, the team would now be responsible for documenting the IQ/OQ/PQ for their particular microservice or container flavor(s).

Cloud Offerings

Serverless architectures (Note: I'm most familiar with AWS, so will use their cloud products as examples. Azure and GCP have similar offerings.) One of the key advantages of the LambdaFargate, RDS, and similar managed/SaaS products is their undifferentiated heavy lifting.  AWS is responsible for the care and maintenance of the underlying infrastructure and servers. For on-prem servers, this is something the organization spends significant time and money on, but these expenditures do not directly benefit the customer.  Serverless allows companies to focus their efforts on things that make a difference to their customers.

How do you ensure IQ/OQ/PQ quality when you don't have control over the servers that are running your application(s)?

Another consideration: Teams will need to take regulatory impact into consideration when selecting new cloud technologies.

Infrastructure as Code (IaC)

The use of IaC (e.g. CloudFormation or Terraform) may require new release cycle processes. I.e since this code is not part of the application, you may want to have a separate release cycle for when the infrastructure is updated. The same is true for container (Docker) code updates.

The FCT should be responsible for the IaC associated with their product as it directly impacts both functionality and performance.

Transformation

When thinking about transforming to a FCT-based organization, the 2019 AWS re:invent keynote by Andy Jassy comes to mind. His "transformation" is referring to migrating from on-premise to cloud infrastructure (AWS, of course), but I think the non-technical transformation recommendations he outlines (start: 5:04 end 11:48) are also applicable to the FCT organizational change:

I think aggressive goals (item #2) is particularly important. Legacy organizations have a lot of inertia that needs to be overcome in order to move things forward. Breaking those initial barriers is even more difficult when you're having to deal with regulatory requirements.

Bottom Line

FDA regulatory requirements add tasks and documentation to the software release process. This has always been the case for medical device companies, but how this additional work is managed when trying to implement full-cycle teams can be a complicated problem to solve.

Just like unregulated development, providing the tooling to automate these tasks is the key to allow teams to deliver quality software to customers more quickly.

---------------

*SRS, Software Requirements Specification. The old-school water-fall requirements document. I don't miss those days!

Software Doesn’t Have An MD

Sunday, January 25th, 2015

Core O.S., core, Photo: Alex Washburn / WIREDI got a kick out of this Andreessen Horowitz piece: Digital Health/SOFTWARE DOESN'T HAVE AN MD.

I'm sure 'the kid in the garage without a degree' is no dummy, but this premise:

And so that large percentage of medicine that is effectively being practiced by non-MDs is going to expand.

is simply ludicrous.

There's a big difference between creating health and wellness appliances and mobile applications and diagnosing and treating patients. The distinction is outlined in FDA clarifies the line between wellness and regulated medical devices.  If you claim your product acts like a doctor (treat or diagnose) or doesn't fall into the "low risk" category, then your company will have to follow FDA regulatory controls.

FDASIA Health IT Report

Saturday, April 5th, 2014

health-it-catagoriesThe Food and Drug Administration Safety and Innovation Act (FDASIA) required the FDA to develop:

a report that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.

Here's the report: FDASIA Health IT Report (warning: PDF).

It looks like EMR/EHR vendors (administrative and health management functionality) don't have to worry about FDA regulatory oversight. The medical device category (of course) does:

FDA would focus its oversight on medical device functionality because, in general, these functions, such as computer aided detection software and remote display or notification of real-time alarms from bedside monitors, present greater risks to patient safety than health IT with administrative or health management functionality.

 

FDA Regulation of Mobile Medical Apps

Monday, September 23rd, 2013

fda-logoThe FDA has issued their final guidance on mobile medical applications: Keeping Up with Progress in Mobile Medical Apps. The guidance document (PDF) will "give mobile app creators a clear and predictable roadmap to help them determine whether or not their products will be the focus of FDA's oversight. "

The regulatory approach is as you would expect (my highlight):

FDA intends to apply its regulatory oversight to only those mobile apps that are medical devices and whose functionality could pose a risk to a patient’s safety if the mobile app were to not function as intended.

There are six categories of mobile applications listed that the FDA intends to exercise enforcement discretion:

  1. Help patients/users self-manage their disease or condition without providing specific treatment suggestions;
  2. Provide patients with simple tools to organize and track their health information;
  3. Provide easy access to information related to health conditions or treatments;
  4. Help patients document, show or communicate potential medical conditions to health care providers;
  5. Automate simple tasks for health care providers; or
  6. Enable patients or providers to interact with Personal Health Records (PHR) or Electronic Health Record (EHR) systems.

If a mobile application is considered a medical device it will be classified as such -- class I (general controls), class II (special controls in addition to general controls), or class III (premarket approval) -- and the manufacturer will be required to follow Quality System regulations (which includes good manufacturing practices, §820.30) in the design and development of that application.

For any organization that is not already under FDA regulatory control, this is a big deal. Given that there are 1000's of medical applications already out there, even this limited scope approach will likely affect many companies. More information is here: Mobile Medical Applications.

The guidance includes many examples (including mobile apps that are not medical devices) and an FAQ.

Also see:

 

FDA Recognition of Medical Device Standards for Interoperability

Sunday, August 11th, 2013

This is a follow-up to Interoperability: Arrested Progress.

The FDA has recognized voluntary interoperability standards for medical devices: Improving Patient Care by Making Sure Devices Work Well Together.

The FDA and HHS has (my highlight):

published a list of recognized standards for interoperability intended to assist manufacturers who elect to declare conformity with consensus standards to meet certain requirements for medical devices.

The standards are searchable here: Recognized Consensus Standards. The Software/Informatics area currently lists 54 items.

Some consider this a "landmark announcement" (see here) but "voluntary" and "elect to declare" just seem like more of #1 (same old, same old) to me.

UPDATE (9/4/2013): More here: FDA Updates List of Recognized Standards, Confusion Ensues

Interoperability: Arrested Progress

Sunday, July 28th, 2013

When it comes to the state of interoperability in the medical device industry there couldn't be a better metaphor than Arrested Development*.  A dysfunctional family made up of eccentric well-meaning personalities each doing their own thing, oblivious to each other and the rest of the world.

Healthcare Un-Interoperability has long been one of my favorite subjects. Let's review where things are these days.

The article Health IT Interoperability: How Far Along Are We? provides a nice summary of the current state of HIT interoperability. This is particularly important because:

hospitals using basic EHR systems tripled from 12.2 percent in 2009 to 44.4 percent in 2012

For better or worse, it's the monetary incentives of the Affordable Care Act that push doctors to electronic medical records and is the primary reason for the accelerated rate of EHR adoption. The goal of having more electronic health records is to improve the quality of patient care. Reduction of medication-related errors is a great example: Lack of Interoperability has Ownership for Medication ErrorsThe rapid uptake of these systems can also present problems. For example, in Emergency Departments: EHR systems pose serious concerns, report says.

Nevertheless, it's clear that electronic medical records is the future in healthcare data management. The down-side of this growth from an interoperability point of view is that there are that many more systems out there that don't talk to each other!

Initiatives like CommonWell and Healtheway are moving in the right direction but are just getting off the ground. Also, these types of efforts are often far removed from the medical device industry and have little impact on software development and interface decision making.

Let's step back and look at the HIMSS definition of Interoperability:

  1. Foundational: Data exchange with no interpretation.
  2. Structural:  Allows identification of data structure (fields) but not necessarily data content.
  3. Semantic: Data structuring and codification (interpretation) of the data.

For all practical purposes only #3 (semantic) has value when in comes to the exchange of data with a medical device. As noted in Interoperability: Not a non-issue:

Semantic interoperability continues to be a major challenge and, if not addressed, will have a serious impact on the quality of care.

The same point is made here: Interoperability vs Health Information Exchange: Setting the Record Straight.  Just because you can send it (exchange) doesn't mean the recipient can understand it (interoperability).

One area that is always part of this discussion are standards. It's unfortunate that due to technical and (mostly) non-technical reasons the following is often true:

standards-vs-interoperability

Even more disheartening is when you read that a standards-based organization (OpenStack in this case) can't necessarily make interoperability magically happen:

... success depends upon a single large vendor assuming leadership. Interoperability will follow, but it won't be designed by committee.

The distress of a well-focused cloud computing API involving a hand-full of vendors makes the outlook for HIT interoperability look particularly bleak.  To make matters worse, the use of OSS in FDA regulated products face additional challenges that are not even seen in most other industries (see Open Source Medical Device Connectivity)

This is all good news for businesses that provide products and services that fill the connectivity gap. Companies like CapsuleiSirona, and Nuvon are many times the only effective way to provide an integration solution to a large number of customers.

I should note that there are some bright spots in the interoperability landscape. For example, the Continua Health Alliance has successfully pulled together over 200 companies to create a vision for inter-operable personal connected health solutions.  Also, the West Health Institute is building standardized communication protocols into their embedded software for medical devices. These and numerous other successes provide hope, but are still just the tip of a very large iceberg.

Dr. Julian Goldman sums up the current situation in Medical Device Interoperability: A ‘Wicked Problem’ of Our Time:

Our years of work on medical device interoperability have led us to see the barriers (including technical, business, liability, standards, and regulatory factors) as “wicked problems,” in which there is little agreement about “the problem,” no agreement on a solution, and problem solving is complex because of external constraints.

Others (Is HIT interoperability in the nature of healthcare?) see the proprietary business model of major HIT companies as the primary culprit.

So what are some possible scenarios for the future?

  1. Same old, same old.  This is essentially Einstein's definition of insanity: doing the same thing over and over again and expecting different results.
  2. Federally enforced standards and regulations.  Dr. Goldman's suggestion to require manufacturers to fully disclosure their communication interfaces?   Given the current anti-regulatory environment and budget restrictions, this seems unlikely to happen.
  3. A hegemon, like OpenStack above?  The healthcare industry is too diverse and complex. There is no single player that could even begin to tip the scales.

At least for the foreseeable future it looks like #1 (insanity) is going to prevail. If I'm missing some huge game-changer, please let me know.

In the mean time, let another episode begin!

                                             
*No deep meaning here. Certainly not like Arrested Criticism.  I'm just comparing the medical device industry to a bunch of fictional crazy people.

Medical Device Innovation Consortium

Wednesday, December 5th, 2012

The FDA has announced the Medical Device Innovation Consortium (MDIC)  which aims to help medical device companies get their products to market faster. See FDA, Private Groups Team Up to Speed Device Approval.

The term Regulatory Science is used 12 times on the single page MDIC Web site so it must be important.  The FDA has been using regulator science in other health related areas since early 2010: see Advancing Regulatory Science.

This consortium is part of a much broader strategy (see the strategic plan) to improve both innovation and safety in  FDA-regulated products. The MDIC site talks about subcommittees and projects but it's unclear what specific medical device topics will be addressed.  It will be interesting to follow their growth and progress.

When Open-source can Kill or Cure

Wednesday, June 6th, 2012

The use of open-source software in medical devices has been a topic of discussion for many years. The Economist article Open-source medical devices: When code can kill or cure highlights continuing activity in the academic community and interest by the FDA in developing processes around its use.

One of the big unknowns in this area is how a community might be formed (Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT  has some thoughts on this).

From the article:

Eventually, medical devices might evolve into collections of specialised (and possibly proprietary) accessories, with the primary computing and safety features managed by an open-source hub.

This is in reference to both hardware and software, but in either case one major challenge will be how to incentivize contributions.  Open-source means free to use and modify. If there is no financial gain to be had, other benefits for contributing need to be developed.  Also, proprietary and open-source in the same sentence seems like an oxymoron, so I'm not sure how that's going to work.

Another barrier would be liability risk. Let's say you contributed software to this hub and that component ended up in a device that harmed or killed someone.  All of the legal waivers, disclaimers, and releases in world wouldn't necessarily keep you out of a court room.

I don't think the basic arguments discussed in Open Source Medical Device Connectivity have changed a great deal.  At the end of the day the medical device manufacturer will ultimately be responsible for ensuring the safety and efficacy of their device.

OTS/SOUP Software Validation Strategies

Thursday, February 16th, 2012

My last discussion of Off-The-Shelf software validation only considered the high-level regulatory requirements.  What I want to do now is dig deeper into the strategies for answering question #5:

How do you know it works?

This is the tough one. The other questions are important, but relative to #5, answering them is pretty easy.  How to answer this question (i.e. accomplish this validation) is the source of a lot of confusion.

There are many business and technical considerations that go into the decision to use OTS or SOUP software as part of a medical device. Articles and books are available that include guidance and general OTS validation approaches. e.g. Off-the-Shelf Software: A Broader Picture (warning PDF) is very informative in this regard:

  • Define business’ use of the system, ideally including use cases and explicit clarification of in-scope and out-of-scope functionality
  • Determine validation deliverables set based on system type, system risk, project scope, and degree of system modification
  • Review existing vendor system and validation documentation
  • Devise strategy for validation that leverages vendor documentation/systems as applicable
  • Create applicable system requirements specification and design documentation
  • Generate requirements-traceable validation protocol and execute validation
  • Put in place system use, administration, and maintenance procedures to ensure the system is used as intended and remains in a validated state

This is great stuff, but unfortunately it does not help you answer question #5 for a particular type of software. That's what I want to try to do here.

OTS really implies Commercial off-the-shelf (COTS) software. The "commercial" component is important because it presumes that the software in question is a purchased product (typically in a "shrink-wrapped" package) that is designed, developed, and supported by a real company.  You can presumably find out what design controls and quality systems are in place for the production of their software and incorporate these findings into your own OTS validation.  If not, then the product is essentially SOUP (keep reading).

Contrast OTS with Software of Unknown Provenance (SOUP).  It is very unlikely that you can determine how this software was developed, so it's up to you to validate that it does what it's supposed to do.  In some instances this may be legacy custom software, but these days it probably means the integration of an open source program or library into your product.

This following list is by no means complete. It is only meant to provide some typical software categories and the strategies used for validating them.  Some notes:

  • I've included a Hazard Analysis section in each category because the amount of validation necessary is dependent on the level of concern.
  • The example requirements are not comprehensive. I just wanted to give you a flavor for what is expected.
  • Always remember, requirements must be testable.  The test protocol has to include a pass/fail criteria for each requirement. This is QA 101, but is often forgotten.
  • I have not included any example test protocol steps or reports.  If you're going to continue reading, you probably don't need help in that area.

Operating Systems

Examples:

  • Windows XP SP3
  • Windows 7 32-bit and 64-bit
  • Red Hat Linux

Approach:

  1. Hazard Analysis: Do a full  assessment of the risks associated with each OS.
    • Pay particular attention to the hazards associated with device and device driver interactions.
    • List all hazard mitigations.
    • Provide a residual Level of Concern (LOC) assessment after mitigation -- hopefully this will be negligible.
    • If the residual LOC is major, then Special Documentation can still be provided to justify its use.
  2. Use your full product verification as proof that the OS meets the OTS requirements. This has validity since your product will probably only be using a small subset of the full capabilities of the OS.  All of the other functionality that the OS provides would be out of scope for your product.
  3. This means that a complete re-validation of your product is required for any OS updates.
  4. There is no test protocol or report with this approach. The OS is considered validated when the product verification has been successfully completed.

Compilers

Examples:

  • Visual Studio .NET 2010  (C# or C++)
Approach:
  1. Hazard Analysis:
    • For a vast majority of cases, I think it is safe to say that a compiler does not directly affect the functioning of the software or the integrity of the data.  What a program does (or doesn't do) depends on the source code, not on the compiled version of that code.
    • The compiler is also not responsible for faults that may occur in devices it controls. The application just needs to be written so that it handles these conditions properly.
    • For some embedded applications that use specialized hardware and an associated compiler, the above will not necessarily be true. All functionality of the compiler must be validated in these cases.
  2. For widely used compilers (like Microsoft products) full product verification can be used as proof of the OTS requirements.
  3. Validation of a new compiler version , e.g. upgrading from VS 2008 to VS 2010: Showing that the same code base compiles and all Unit Tests pass in both can be used as proof. This assumes of course that the old version was previously validated.
  4. The compiler is considered fit for use after the product verification has passed so there is also no test protocol or report in this case.

Integrated Libraries

Examples:

Approach:
  1. Hazard Analysis: Both of these open source libraries are integrated into the product software.  The impact on product functioning, in particular data integrity, must be fully assessed.
  2. You first list the requirements that you will be using. For example, typical logging functionality that might include:
    • The logging system shall be able to post an entry labeled as INFO in a text file .
    • The logging system shall be able to post an entry labeled as INFO in a LEVEL column of a SQL Server database.
    • ... same for ERROR, DEBUG, WARN, etc.
    • The logging system shall include time/date and other process information formatted as "YYYY-MM-DD HH:MM:SS..." for each log entry.
    • The logging system shall be able to log exceptions at all log levels, and include full stack traces.
  3. For database functionality, listing basic CRUD requirements plus other specialized needs can be done in the same way.
  4. I have found that the easiest way to test these kinds of requirements is to simply write unit tests that prove the library performs the desired functionality.  The unit tests are essentially the protocol and a report showing that all asserts have passed is a great artifact.

Version Control Systems

Examples:

Approach:
  1. Hazard Analysis: These are configuration management tools and are not part of the product. As such, the level of concern is generally low.
  2. As above,  you first list the specific functionality that you expect the VCS to perform. Here are some examples of the types of requirements that need to be tested:
    • The product shall be able to add a directory to a repository.
    • The product shall be able to add a file to a repository.
    • The product shall be able to update a file in a repository.
    • The product shall be able to retrieve the latest revision of files and directories.
    • The product shall be able to  branch a revision of files and directories.
    • The product shall be able to merge branched files and directories.
  3. You then write a protocol that tests each one. This would include detailed instructions on how to perform these operations along with the pass/fail criteria for each requirement.

Issue Tracking Tools

Examples:

Approach:
  1. Hazard Analysis: These tools are used for the management of the development project. Again, the level of concern is generally low.
  2. You only need to validate the functionality you intend to use.  The features that you don't use do not need to be tested.
  3. You simply need to test the specific functionality.  Some example requirements -- the roles, naming conventions, and workflow will of course depend on your organization and the tool being used:
    • A User shall be able to create a new issue.
    • A User shall be able to comment on an issue.
    • A Project Manager shall be able to assign an issue to a Developer.
    • A Developer shall be able change the state of an issue to 'ready for test'.
    • A Tester shall be able to change the state of an issue to 'verified'.
    • The tool shall be able to send e-mail notifications when an issue has been modified.
    • An Administrator shall be able to define a milestone.
  4. A protocol with detailed instructions and pass/fail criteria is executed and reported on.

Validation is a lot of work but is necessary to ensure that all of the tools and components used in the development of medical device software meet their intended functionality.

Building Safety into Medical Device Software

Saturday, January 7th, 2012

The article Build and Validate Safety in Medical Device Software takes a critical look at the current processes for medical device software and concludes:

The complexity of the software employed in many medical devices has rendered inadequate traditional methods (testing) for demonstrating their safety.

The article then provides examples of the types of analyses that can be performed to better ensure safety.

Interesting read.

Here are some references:

BohrBug: Not necessarily easy to find, but once discovered is reproducible.

Heisenbug: The ever-annoying bug that can not be reliably reproduced.

Spin: An open-source software tool for formal verification of distributed software systems.