{"ID":78536,"post_author":"9203512","post_date":"2019-01-04 17:48:47","post_date_gmt":"0000-00-00 00:00:00","post_content":"","post_title":"Software Development for Medical Devices Using Continuous Integration: A Brief Introduction","post_excerpt":"","post_status":"draft","comment_status":"closed","ping_status":"closed","post_password":"","post_name":"","to_ping":"","pinged":"","post_modified":"2019-01-04 17:48:47","post_modified_gmt":"2019-01-04 22:48:47","post_content_filtered":"","post_parent":0,"guid":"https:\/\/www.limsforum.com\/?post_type=ebook&p=78536","menu_order":0,"post_type":"ebook","post_mime_type":"","comment_count":"0","filter":"","_ebook_metadata":{"enabled":"on","private":"0","guid":"5EA0EF41-76B3-4614-B076-00D29C4282B3","title":"Software Development for Medical Devices Using Continuous Integration: A Brief Introduction","subtitle":"","cover_theme":"nico_18","cover_image":"https:\/\/www.limsforum.com\/wp-content\/plugins\/rdp-ebook-builder\/pl\/cover.php?cover_style=nico_18&subtitle=&editor=Shawn+Douglas&title=Software+Development+for+Medical+Devices+Using+Continuous+Integration%3A+A+Brief+Introduction&title_image=https%3A%2F%2Fs3.limsforum.com%2Fwww.limsforum.com%2Fwp-content%2Fuploads%2FContinuous-integration-dhf.jpg&publisher=LabLynx+Press","editor":"Shawn Douglas","publisher":"LabLynx Press","author_id":"26","image_url":"","items":{"c52457e4a7209968c2325bdf3bcebdb3_type":"article","c52457e4a7209968c2325bdf3bcebdb3_title":"Practical application of Agile","c52457e4a7209968c2325bdf3bcebdb3_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Practical_Application_of_Agile","c52457e4a7209968c2325bdf3bcebdb3_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Practical Application of Agile\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\nTicketing system as a trigger for code peer review \nSomewhat recently I was thinking about what ticket status might be appropriate when using issue tracking for all tasks from functional requirements to documentation to defect tracking. It got me thinking about the need for peer reviews of code and how tedious these reviews can be. It turns out there is at least one plugin for Trac that includes hooks for annotation of code for the sake of peer review. It does not, however, appear to include any kind of formal sign-off capability.\nI started thinking that it would be nice to have a plugin for peer reviews (for Trac or Redmine or whatever). Used wisely, however, defining our workflow in a manner that makes the peer review process an integral part of it, we can probably simplify things. Do we really need a plugin, or can we simply use an \"In-Review\" status to achieve the same thing? I suppose the answer to this depends on how strict you want to be.\nHere\u2019s what I\u2019m thinking with regard to the history of a ticket (or issue, task, work item, or whatever we choose to call it):\n\n New\n In-Progress\n Resolved (or, if we determine that a ticket should not be completed, we have alternatives, such as deferred, rejected, duplicate, etc.)\n In-Review\n Closed\nWith a setup such as this, we can use the \"Resolved\" status as an indicator that an Issue has been completed, but it is not yet ready to be closed. Tickets are only closed when appropriate peer review actions have been taken. Who determines what these actions are? That is up to the project manager (or the team lead), and it is enforced by proper routing of the ticket. Easy individual responsible for peer review is assigned the ticket. Seeing the \"In-Review\" status, this colleague reviews the code changes (observing the changeset that is attached to the ticket) and makes comments (in the ticket notes).\nI know this sounds like a bit of legwork, but I see a few major benefits of an approach like this:\n\nTracing - We now have an audit log of all peer review comments. Using our ticket system with configuration management integration, tickets, changesets and review comments are linked together and not lost in some email thread or document somewhere.\nTime Savings \u2013 Anyone who has ever sat through a peer review (and I\u2019m guessing most project managers and developers have) knows how insanely time consuming they can be. Because nobody ever seems to have time, we attempt to save time by doing a large review of code; We wait for a long time, and then we are faced with a peer review involving an overwhelming amount of code. This leads to the next benefit\u2026\nBetter Focus of Reviews - I don\u2019t know about you, but I find that I am much better at reviewing a smaller amount of code or a single functional area than attempting to review thousands of lines of code all at once. We\u2019re all busy, and this isn\u2019t going to change. What happens when you find out that you have a peer review at the end of the week and you have to read through and mark up 5 class files? Do you set aside everything you are working on and do it? You try, but time is short, and so you hurry.\nCommunication - When I take the time to review a changeset, it benefits both team and the individual performing the review. Now I am better informed about what others are working on, where it is implemented, how it is implemented, etc. I don\u2019t have to go bug Joe the Developer to ask him if he finished such-and-such. I already know that he did because I reviewed his code.\nThis all assumes that our team follows good project management when it comes to the handling of issue tracking and version control. It means that we have to have well organized tickets and we have to commit changesets in some meaningful fashion. This should be a no-brainer.\n\nReferences \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Practical_Application_of_Agile\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Practical_Application_of_Agile<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 23:23.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 277 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","c52457e4a7209968c2325bdf3bcebdb3_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Practical_Application_of_Agile skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Practical Application of Agile<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n<h2><span class=\"mw-headline\" id=\"Ticketing_system_as_a_trigger_for_code_peer_review\">Ticketing system as a trigger for code peer review<\/span><\/h2>\n<p>Somewhat recently I was thinking about what ticket status might be appropriate when using issue tracking for all tasks from functional requirements to documentation to defect tracking. It got me thinking about the need for peer reviews of code and how tedious these reviews can be. It turns out there is at least one plugin for Trac that includes hooks for annotation of code for the sake of peer review. It does not, however, appear to include any kind of formal sign-off capability.\n<\/p><p>I started thinking that it would be nice to have a plugin for peer reviews (for Trac or Redmine or whatever). Used wisely, however, defining our workflow in a manner that makes the peer review process an integral part of it, we can probably simplify things. Do we really need a plugin, or can we simply use an \"In-Review\" status to achieve the same thing? I suppose the answer to this depends on how strict you want to be.\n<\/p><p>Here\u2019s what I\u2019m thinking with regard to the history of a ticket (or issue, task, work item, or whatever we choose to call it):\n<\/p>\n<ul><li> New<\/li>\n<li> In-Progress<\/li>\n<li> Resolved (or, if we determine that a ticket should not be completed, we have alternatives, such as deferred, rejected, duplicate, etc.)<\/li>\n<li> In-Review<\/li>\n<li> Closed<\/li><\/ul>\n<p>With a setup such as this, we can use the \"Resolved\" status as an indicator that an Issue has been completed, but it is not yet ready to be closed. Tickets are only closed when appropriate peer review actions have been taken. Who determines what these actions are? That is up to the project manager (or the team lead), and it is enforced by proper routing of the ticket. Easy individual responsible for peer review is assigned the ticket. Seeing the \"In-Review\" status, this colleague reviews the code changes (observing the changeset that is attached to the ticket) and makes comments (in the ticket notes).\n<\/p><p>I know this sounds like a bit of legwork, but I see a few major benefits of an approach like this:\n<\/p>\n<ol><li><b>Tracing<\/b> - We now have an audit log of all peer review comments. Using our ticket system with configuration management integration, tickets, changesets and review comments are linked together and not lost in some email thread or document somewhere.<\/li>\n<li><b>Time Savings<\/b> \u2013 Anyone who has ever sat through a peer review (and I\u2019m guessing most project managers and developers have) knows how insanely time consuming they can be. Because nobody ever seems to have time, we attempt to save time by doing a large review of code; We wait for a long time, and then we are faced with a peer review involving an overwhelming amount of code. This leads to the next benefit\u2026<\/li>\n<li><b>Better Focus of Reviews<\/b> - I don\u2019t know about you, but I find that I am much better at reviewing a smaller amount of code or a single functional area than attempting to review thousands of lines of code all at once. We\u2019re all busy, and this isn\u2019t going to change. What happens when you find out that you have a peer review at the end of the week and you have to read through and mark up 5 class files? Do you set aside everything you are working on and do it? You try, but time is short, and so you hurry.<\/li>\n<li><b>Communication<\/b> - When I take the time to review a changeset, it benefits both team and the individual performing the review. Now I am better informed about what others are working on, where it is implemented, how it is implemented, etc. I don\u2019t have to go bug Joe the Developer to ask him if he finished such-and-such. I already know that he did because I reviewed his code.<\/li><\/ol>\n<p>This all assumes that our team follows good project management when it comes to the handling of issue tracking and version control. It means that we have to have well organized tickets and we have to commit changesets in some meaningful fashion. This should be a no-brainer.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<\/div>\n\n<!-- \nNewPP limit report\nCached time: 20190104224854\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.011 seconds\nReal time usage: 0.014 seconds\nPreprocessor visited node count: 37\/1000000\nPreprocessor generated node count: 304\/1000000\nPost\u2010expand include size: 135\/2097152 bytes\nTemplate argument size: 0\/2097152 bytes\nHighest expansion depth: 4\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 4.618 1 - Template:Reflist\n100.00% 4.618 1 - -total\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8687-0!*!0!!*!*!* and timestamp 20190104224854 and revision id 25247\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Practical_Application_of_Agile\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Practical_Application_of_Agile<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","c52457e4a7209968c2325bdf3bcebdb3_images":[],"c52457e4a7209968c2325bdf3bcebdb3_timestamp":1546642134,"fe175ec1d1846bbf56d90860f4b8b11a_type":"article","fe175ec1d1846bbf56d90860f4b8b11a_title":"Validation","fe175ec1d1846bbf56d90860f4b8b11a_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation","fe175ec1d1846bbf56d90860f4b8b11a_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Validation\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\nContents\n\n1 Overview of unit tests \n\n1.1 Early attempts to automate functional testing \n1.2 Automating functional tests using unit test framework \n1.3 What is a good unit test? \n\n\n2 What is the value of unit testing? \n\n2.1 Immediate feedback within continuous integration: Developer confidence \n\n2.1.1 Easy refactoring \n2.1.2 Regression tests with every code change \n2.1.3 Concurrency tests \n2.1.4 Repeatable and traceable test results \n2.1.5 Regulated environment needs \n2.1.6 Document the approach \n2.1.7 Label and trace tests \n\n\n\n\n3 The traceability matrix \n\n3.1 Do we still need manual tests? \n\n\n4 Notes \n5 References \n\n\n\nOverview of unit tests \nIn computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. In object-oriented programming a unit is usually a method. Unit tests are created by programmers or occasionally by white box testers during the development process. In the world of Java, we have a number of popular options for the implementation of unit tests, with JUnit and TestNG being, arguably, the most popular. Examples provided in this article will use TestNG syntax and annotations.\nTraditionally (and by traditionally, I mean in their relatively brief history), unit tests have been thought of as very simple tests to validate basic inputs and outputs of a software method. While this can be true, and such simple tests can serve of some amount of value, it is possible to achieve much more with unit tests. In fact, it is not only possible but recommended that we implement much of our user acceptance, functional, and possibly even some non-functional tests within a unit test framework.\nTo further enhance quality, we can augment the acceptance with unit tests.[1] While I personally have never been a fan of test-driven development (I feel that the assumptions required by test-driven development do not allow for a true iterative approach), I do believe that creation of unit tests in parallel with development leads to much more quality software. In the world of Agile, this means that no functional requirement (or user story) is considered fully implemented without a corresponding unit test. This strict view of unit tests may be a bit extreme, but it is not without merit.\nThe first unit test a developer may ever write is likely so simple that it's nearly useless. It may go something like this.\nGiven a method:\n\npublic int doSomething (int a, int b) { \u2026 return c;}\nA simple unit test may look something like this:\n\npublic class MyUnitTests { @Test public void testDoSomething() { assertEquals(doSomething(1, 2), expectedResult); }}\nGiven a very simple method the developer is able to assert that, essentially, a + b = c. This is easy to write, and there is little overheard involved, but it really isn\u2019t a very useful unit test.\n\nEarly attempts to automate functional testing \nLong ago I was involved with a project in which management invested a significant amount of time and training in an attempt to implement automated testing. The chosen tool was Rational Robot (now an IBM product). The idea behind tools such as Robot was that a test creator could record test macros, note points of verification, and replay the macros later with test results noted. Tools such as Rational Robot and WinRunner attempted to replace the human tester with record scripts. These automated scripts could be written using a scripting language or, more commonly, by recording mouse movements, clicks, and keyboard actions. In this regard, these tools of test automation allowed black-box testing through a user interface.\nIn this over-simplified view of automated testing, there were simply too many logistical problems with test implementation to make them practical. Any minor changes to the user interface would result in a broken test script. Those responsible for maintaining these automated scripts often found themselves spending more time maintaining the tests than using them for actual application testing.\nRational Robot and tools like it are alive and well, but I refer to them in the past tense because such tools, in my experience, have proven themselves to be a failure. I say this because I have personally spent significant amounts of time creating automated scripts in such tools, and I have been frustrated to learn later that they would not be used because of the substantial amount of interface code that changes as a project progresses. Such changes are absolutely expected, and yet, a recorded automated test does not lend itself well to an iterative development environment or an ongoing project.\n\nAutomating functional tests using unit test framework \nMost software projects, especially in any kind of Agile environment, undergo frequent changes and refactoring. If the traditional single-flow waterfall model worked, recorded test scripts such as those noted previously would probably work just fine as well, albeit with little benefit.\nBut it should be well known by know that the traditional single-flow waterfall model has failed, and we live in an iterative\/Agile world. As such, our automated tests must be equally equipped for ongoing change. And because the functional unit tests are closely related to requirements at both a white-box and black-box level, developers, not testers, have an integral role in the creation of automated tests.\nTo achieve this level of unit testing, a test framework must be in place. This requires a bit of up-front effort, and the details of creating such a framework go well beyond the scope of this article. Additionally, the needs of a test framework will vary depending on the project.\nTest fixtures become an important part of complex functional unit testing. A test fixture is a class that incorporates all of the setup necessary for running such unit tests. It provides methods that can create common objects (for example, test servers and mock interfaces). The details included in a test fixture are specific to each project, but some common methods include test setup, simulation, and mock object creation and destruction, as well as declaration of any common functionality to be used across unit tests. To provide further detail on test fixture creation would require much more detail than can be provided here.\nGiven what may seem like extreme overhead in the creation of complex unit tests, we may begin to question the value. There is, no doubt, a significant up-front cost to the creation of a versatile and useful unit test framework (including a test fixture, which includes all the necessary objects and setup needed to simulate a running environment for the sake of testing). And given the fact that manual function and user acceptance testing remains a project necessity, it seems like there may be an overlap of effort.\nBut this is not the case.\nWith a little up-front creation of a solid unit test framework, we can make efforts to create unit tests simple. We can even go as far as requiring a unit test for any functional requirement implementation prior to allowing that requirement (or ticket) to be considered complete. Furthermore, as we discover potential functionality problems, we have the opportunity to introduce a new test right then and there!\nThe hardware system, software program, and general quality assurance system controls discussed below are essential in the automated manufacture of medical devices. The systematic validation of software and associated equipment will assure compliance with the QS regulation and reduce confusion, increase employee morale, reduce costs, and improve quality. Further, proper validation will smooth the integration of automated production and quality assurance equipment into manufacturing operations. Medical devices and the manufacturing processes used to produce them vary from the simple to the very complex. Thus, the QS regulation needs to be and is a flexible quality system. This flexibility is increasingly valuable as more device manufacturers move to automated production, test\/inspection, and record-keeping systems.[2]\n\nWhat is a good unit test? \nIn his book Safe and Sound Software, Thomas H. Faris describes the unit test as such:\n\nSoftware testing may occur on software modules or units as they are completed. Unit testing is effective for testing units as they are completed, when other units are components have not yet been completed. Testing still remains to be completed to ensure that the application will work as intended when all software units or components are executed together.[3]\nThis is a start, but unit tests can achieve so much more! Faris goes on to describe a number of different categories of software[3]:\n\n Black box test\n Unit test\n Integration test\n System test\n Load test\n Regression test\n Requirements-based test\n Code-based test\n Risk-based test\n Clinical test\nTraditionally this may be considered a fair list. Used wisely, and with the proper frame work, however, we can perform black box, integration, system, load, regression, requirements, code-based, risk-based, and clinical tests with efficient unit tests that simulate a true production environment. The purpose of this article is not to go into the technical details of how (to explain unit test frameworks, fixtures, mock objects and simulations would require much more space). Rather, I simply want to point out the benefits that result. To achieve these benefits, your software team will need to develop a deep understand of unit tests. It will take some time, but it will be time very well spent.\nIt\u2019s a good idea to have unit tests that go above and beyond what we traditionally think of as unit tests, and go several steps further, automating functional testing. This is another one of those areas where team members often (incorrectly) feel that there is not sufficient time to do all the work. As Harris goes on to state:\n\nSoftware testing and defect resolution are very time-consuming, often draining more than one-half of all effort undertaken by a software organization ... Testing need not wait until the entire product is completed; iteratively designed and developed code may be tested as each iteration of code is completed. Prior to beginning of verification or validation, the project plan or other test plan document should discuss the overall strategy, including types of tests to be performed, specific functional tests to be performed, and a designation of test objectives to determine when the product is sufficiently prepared for release and distribution.[3]\nHarris is touching on something that is very important in our FDA-regulated environment, and this is the fact that we must document and describe our tests. For our unit tests to be useful we must provide documentation of what each test does (that is, what specifically it is testing) and what the results are. The beauty of unit tests and the tools available (incorporation into our continuous integration environment) is that this process is streamlined in a way that makes the traceability and re-creation of test conditions required for our 510(k) extremely easy!\nTo achieve all of this we will need to have a testing framework capable of application launch, simulations, mock objects, mock interfaces and temporary data persistence. This all sounds like much more overhead than it actually is, but fear not: the benefits far outweigh the costs.\n\nWhat is the value of unit testing? \nImmediate feedback within continuous integration: Developer confidence \nToo often we view testing as an activity that occurs only at specific times during software development. At worst, software testing takes place upon completion of development (which is when it is learned that development is nowhere near complete). In other more zealous environments, it may take place at the end of each iteration. We can do better! How about complex unit tests performing validation continuously, with each code change? It is possible to perform full regression tests with every single code change. It sounds like a significant amount of overhead, but it is not. The real cost to a project is not inattention to complex functional unit tests; the danger is that we put off testing until it is too late to react to a critical issue discovered during some predetermined testing phase.\nThe most effective way of killing a project is to organize it so that testing becomes an activity that is so critical to its success that we do not allow for the possibility that testing can do what it is supposed to do: discover a defect prior to go-live.\nAt its most basic level, a continuous integration build environment does just one thing: it runs whatever scripts we tell it to. To that end, it is important that the CI build execute unit tests and that a failure of any single unit test is considered a failure of the continuous integration build. The power of a tool such as Jenkins is that we can tell it to run whatever we want, log the outcome, keep build artifacts, run third-party evaluation tools, and report on results. With integration of our software version control system (e.g., Subversion, Git, Mercurial, CVS, etc.), we know the changeset relevant to a particular build. It can be configured to generate a build at whatever interval we want (nightly, hourly, every time there is a code commit, etc.). When a test fails, we know immediately what changeset was involved.\nPersonally, every time I do any code commit of significance, one of the first things I do is check the CI build for success. If I've broken the build, I get to work on correcting the problem (and if I cannot correct the problem quickly, I roll my changeset out so that the CI build continues to work until I\u2019ve fixed the issue).\n\nEasy refactoring \nAs a developer, refactoring can be a scary thing. Refactoring is perhaps the most effective way of introducing a serious defect while doing something that seems innocuous. With thorough unit tests performing a full regression test with each and every committed software changeset, however, a developer can have confidence that his or her simple code changes have not introduced a defect. We have continuous integration builds running our tests for many reasons, not the least of which is to alert developers to the possibility that their changes have broken the build.\nAs a developer I strive to avoid breaking the continuous integration build. When I do break it, however, I am very pleased to know that what was done to cause a problem has been discovered immediately. Correction of a defect becomes much more costly when its discovery is not noticed until the end of a development phase!\n\nRegression tests with every code change \nBy \"repeated\" I mean something different than repeatable. The fundamental benefit with repeated tests is the fact that a test can be executed many more times by automation than by a human tester. Sometimes, even without a related code change, and much to our surprise, we see a test suddenly fail where it succeeded numerous times before. What happened?\nThe most difficult software defects to fix (much less, find) are the ones that do not happen consistently. Database locking issues, memory issues, deadlock bugs, memory leaks, and race conditions can result in such defects. These defects are serious, but if we never detect them, how can we fix them?\nAs stated previously, it is imperative that have unit tests that go above and beyond what we traditionally think of as unit tests, going several steps further, automating functional testing). This is another one of those areas where team members often (incorrectly) feel that there is not sufficient time to deal with the creation of unit tests. Given a proper framework, however, creation of unit tests need not be overwhelming.\nAnother occasional issue has to do with misuse of the software version control system. Many developers know the frustration that can come with an accidental code change resulting from one developer stepping over the modifications of another. While this is a rare issue in a properly used version control environment, it does still happen, and unit tests can quickly reveal such a problem at build time.\n\nConcurrency tests \nConcurrency tests are tricky, and it is in concurrency testing that the repeated and rapid nature of functional unit tests can shine where human testers cannot. I personally have witnessed many occasions in which a CI build suddenly fails for no obvious reason. There was no code commit related to the particular point-of-failure, and yet a unit test that once succeeded suddenly fails? Why?\nThis can happen (and it does happen) because concurrency problems, by their very nature, are hit or miss. Sometimes they are so unlikely to occur that we never witness them during the course of normal testing. When a continuous integration environment runs concurrency tests dozens of times a day, however, we increase the likelihood of finding a hidden and menacing problem. Additionally, unit tests can simulate many concurrent users and processes in a way that even a team of human testers cannot.\n\nRepeatable and traceable test results \nThis is the key to making our unit tests adhere to the standards we have set forth in our quality system so that we may use them as a part of our submission (see the following section on Regulated Environment Needs). If we are going to put forth the effort, and since we already know that unit tests result in a quality improvement to our software, why wouldn\u2019t we want to include these test results?\nOur continuous integration server can and should be used to store our unit test results right alongside each and every build that it performs.\nThis is a benefit not only in the world of an FDA-regulated environment, of course. In any software project it can be difficult to recreate conditions under which a defect was discovered. With a CI build executing our build and test scripts under a known environment with a known set of files (the CI build tool pulls from the version control system), it is possible to execute the tests under exact and specific circumstances.\nMany of the benefits of functional unit testing listed above are gained only when unit tests are written alongside design and development (test-driven methodologies aside). It is imperative that the development team develop and observe test results while design and activities take place. This is of benefit to the quality assurance team as well, as Dean Leffingwell notes:\n\nA comprehensive unit test strategy prevents QA and test personnel from spending most of their time finding and reporting on code-level bugs and allows the team to move its focus to more system-level testing challenges. Indeed, for many agile teams, the addition of a comprehensive unit test strategy is a key pivot point in their move toward true agility \u2014 and one that delivers \"best bang for the buck\" in determining overall system quality.[4] Also, it is probably becoming clear that a key benefit of functional unit tests is the real-time feedback offered to the development team. Humble and Farley refer to the unit tests that are executed with each software change as \"commit tests.\"[5]\nCommit tests that run against every check-in provide us with timely feedback on problems with the latest build and on bugs in our application in the small.[5] Project unit tests, which should offer significant amount coverage (at least 80 percent), provide the team with built-in software change-commit acceptance criteria. If a developer causes the CI build to fail because of a code change, it is immediately known that the change involved does not meet minimum accepted criteria, and it requires urgent attention.\nHumble and Farley continue:\n\nCrucially, the development team must respond immediately to accepted test breakages that occur as part of the normal development process. They must decided if the breakage is a result of a regression that has been introduced, an intentional change in the behavior of the application, or a problem with the test. Then they must take appropriate action to get the automated acceptance test suite passing again.[5]\nRegulated environment needs \nPer 21 CFR Part 820.30 on design controls:\n\n(f) Design verification. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the design history file (DHF).[6]\nSimply put, our functional unit tests must be a part of our DHF, and we must document each test and test result (success or failure) as well as tie tests and outcomes to specific software releases. This is made extremely easy with a continuous integration environment in which builds and build outcomes (including test results) are stored on a server, labeled, and linked to from our DHF. Indeed, what is sometimes a tedious task when it comes to manual execution and documentation of test results becomes quite convenient.\nThe same is true of design validation:\n\n(g) Design validation. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.[6]\nBecause our CI environment packages build and test conditions at a given point in time, we can successfully satisfy the requirements laid out by 21 CFR Part 820.30 (f) and (g) with very little effort. We simply allow our CI environment to do that which is does best, and that which a human tester may spend many hours attempting to do with accuracy.\n\nDocument the approach \nAs discussed, all these tests are indeed very helpful to the creation of good software. However, without a wise approach to incorporation of such tests in our FDA-regulated environment, they are of little use in any auditable capacity. It is necessary to document our approach to unit test usage and documentation within our standard operating procedures (SOPs) and work instructions, and this is to be documented in much the same way that we would document any manual verification and validation test activities.\nTo this end, it is necessary to make our unit tests and their outputs an integral part of our DHF. Each test must be traceable, and this means that unit tests are given unique identifiers. These unique identifiers are very easily assigned using an approach in which we organize tests in logical units (for example, by functional area) and label tests sequentially.\n\nLabel and trace tests \nAn approach that I have taken in the past is to assign some high-level numeric identifier and a secondary sub-identifier that is used for the specific test. For example, we may have the following functional areas: user session, audit log, data input, data output, and web user interface tests (these are very generic examples of functional areas, granted). Given such functional areas, I would label each test using test naming annotations, with the following high level identifiers:\n\n 1000: user session tests\n 2000: audit log tests\n 3000: data input tests\n 4000: data output tests\n 5000: web user interface tests\nWithin each test it is then necessary to go a step further, applying some sequential identifier to each test. For example, the user test package may include tests for functional requirements such as user login, user logout, session expiration, and a multiple-user login concurrency test. In such a scenario, we would label the tests as follows:\n\n 1000_010: user login\n 1000_020: user logout\n 1000_030: session expiration\n 1000_040: multiple concurrent user login\nUsing TestNG syntax, along with proper Javadoc comments, it is very easy to label and describe a test such that inclusion in our DHF is indeed very simple.\n\n\/** * Test basic user login and session creation with a valid user. * * @throws Exception *\/@Test(dependsOnMethods = {\"testActivePatientIntegrationDisabled\"}, groups = {\"TS0005_AUTO_VE1023\"})public void testActivePatientIntegrationEnabled() throws Exception { Fixture myApp new Fixture(); UserSession mySession = fixture.login(\u201ctest_user\u201d, \u201ctest_password\u201d); assertNotNull(mySession); asertTrue(mySession.active());}\nAny numbering we choose to use for these tests is fine, as long as we document our approach to test labeling in some project level document, for example a validation plan or master test plan. Such decisions are left to those who design and apply a quality system for the FDA-regulated project. As most of us know by now, the FDA doesn\u2019t tell us exactly how we are to do things; rather, we are simply told that we must create a good quality system, trace our requirements through design, incorporate the history in our DHF, and recreate build and test conditions.\nIf I make this all sound a little too easy, it is because I believe it is easy. Too often we view cGMP guidance as a terrible hindrance to productivity, but we are in control of making things as efficient as we can.\n\nThe traceability matrix \nA critical factor in making unit tests usable in an auditable manner is incorporating them into the traceability matrix. As with any test, requirements, design elements, and hazards must be traced to one another through use of the traceability matrix.\n\nThe project team must document traceability of requirements through specification and testing to ensure that all requirements have been tested and correctly implemented (product requirements traceability matrix).[3]\nWith each automated test labeled, we can use the built-in JUnit or TestNG funcationality (along with XSLT, if we so choose) to create output that is tied to the build number and changset and traceable within our trace matrix. The output of our tests (which are run during each continuous integration build) may be as follows:\n\nTEST NAME STATUSTS0005_AUTO_VE1022 PASSTS0005_AUTO_VE1023 PASS TS0005_AUTO_VE1024 FAILTS0005_AUTO_VE1025 SKIP\u2026\nNaturally, we hope that all the automated tests pass, but when they fail we need to record the failure. Its my opinion that placing all test outcomes in the DHF is not necessary. Rather, the DHF can point to the continuous integration build server, where automated test results are bundled alongside each build. Finally, at the end of a sprint or iteration, the appropriate test results for the final locked down build are captured in the DHF and traced appropriately per SOPs.\nOur SOPs and work instructions will require that we prove traceability of our tests and test results, whether manual or automated unit tests. Just as has always been done with the manual tests that we are familiar with, tests must be traced to software requirements, design specifications, hazards, and risks. The goal is simply to prove that we have tested that which we have designed and implemented, and in the case of automated tests, this is all very easy to achieve!\n\nDo we still need manual tests? \nYes! Absolutely! There are a number of reasons why manual tests are still, and always will be, required. Take for example installation qualification and environmental tests. Both manual and automated tests are valid and valuable, and neither should be considered a replacement for the other.\nI recall being a child in karate lessons. One day I came home from a lesson, very proud that I had learned to block a punch. \"Come at me with a punch,\" I said to my friend.\nDoing what I asked, he punched me right in the chest, and I failed to block the punch. This punch wasn't thrown the way I expected (the way we practiced in karate lessons).\n\"No, no, no! You\u2019re punching me the wrong way!\" I said. I only knew how to block one kind of punch, and when punched a different way, my block no longer worked. To me, this karate lesson highlights the difference between an exception and an error. Automated tests can provide error test coverage very well. But when thrown something unanticipated, they don\u2019t offer the creativity in and of themselves to find the issue.\nIt is up to us, developers and testers, to come up with creative punches to throw at our system. This is where manual testing allows a certain amount of \"creative\" punching that may not be considered during unit test development. Manual tests also lead to greater insight related to usability and user interaction issues.\nPerhaps even more importantly, manual tests give feedback on general application usability and user interaction. To this end, a defect that is discovered during manual testing should result in an automated test.\n\nNotes \nThe original author had anticipated writing about the following sub-topics but never did: test fixture, mock objects, avoiding the Singleton design pattern, in-memory DB, and in-memory servlet container.\n\nReferences \n\n\n\u2191 Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional. p. 61. ISBN 9780321635846.   \n\n\u2191 \"General Principles of Software Validation; Final Guidance for Industry and FDA Staff\". Food and Drug Administration. 11 January 2002. http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/GuidanceDocuments\/ucm085281.htm . Retrieved 27 April 2016 .   \n\n\u2191 3.0 3.1 3.2 3.3 Faris, T.H. (2006). Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations. ASQ Quality Press. p. 118\u2013123. ISBN 0873896742.   \n\n\u2191 Leffingwell, D. (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley Professional. p. 196. ISBN 9780321635846.   \n\n\u2191 5.0 5.1 5.2 Humble, J.; Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional. p. 124. ISBN 9780321601912.   \n\n\u2191 6.0 6.1 \"Title 21--Food and Drugs, Part 820--Quality System Regulation, Sec. 820.30 Design controls\". CFR - Code of Federal Regulations Title 21. Food and Drug Administration. 21 August 2015. https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30 . Retrieved 27 April 2016 .   \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation<\/a>\n\t\t\t\t\tCategory: Pages with syntax highlighting errors\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 23:13.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 691 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","fe175ec1d1846bbf56d90860f4b8b11a_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Validation skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Validation<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n\n\n<h2><span class=\"mw-headline\" id=\"Overview_of_unit_tests\">Overview of unit tests<\/span><\/h2>\n<p>In computer programming, unit testing is a method by which individual units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual function or procedure. In object-oriented programming a unit is usually a method. Unit tests are created by programmers or occasionally by white box testers during the development process. In the world of Java, we have a number of popular options for the implementation of unit tests, with JUnit and TestNG being, arguably, the most popular. Examples provided in this article will use TestNG syntax and annotations.\n<\/p><p>Traditionally (and by traditionally, I mean in their relatively brief history), unit tests have been thought of as very simple tests to validate basic inputs and outputs of a software method. While this can be true, and such simple tests can serve of some amount of value, it is possible to achieve much more with unit tests. In fact, it is not only possible but recommended that we implement much of our user acceptance, functional, and possibly even some non-functional tests within a unit test framework.\n<\/p><p>To further enhance quality, we can augment the acceptance with unit tests.<sup id=\"rdp-ebb-cite_ref-LeffingwellAgile11_1_1-0\" class=\"reference\"><a href=\"#cite_note-LeffingwellAgile11_1-1\" rel=\"external_link\">[1]<\/a><\/sup> While I personally have never been a fan of test-driven development (I feel that the assumptions required by test-driven development do not allow for a true iterative approach), I do believe that creation of unit tests in parallel with development leads to much more quality software. In the world of Agile, this means that no functional requirement (or user story) is considered fully implemented without a corresponding unit test. This strict view of unit tests may be a bit extreme, but it is not without merit.\n<\/p><p>The first unit test a developer may ever write is likely so simple that it's nearly useless. It may go something like this.\n<\/p><p>Given a method:\n<\/p>\n<div class=\"mw-highlight mw-content-ltr\" dir=\"ltr\"><pre>public int doSomething (int a, int b) { \u2026 return c;}<\/pre><\/div>\n<p>A simple unit test may look something like this:\n<\/p>\n<div class=\"mw-highlight mw-content-ltr\" dir=\"ltr\"><pre>public class MyUnitTests { @Test public void testDoSomething() { assertEquals(doSomething(1, 2), expectedResult); }}<\/pre><\/div>\n<p>Given a very simple method the developer is able to assert that, essentially, a + b = c. This is easy to write, and there is little overheard involved, but it really isn\u2019t a very useful unit test.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Early_attempts_to_automate_functional_testing\">Early attempts to automate functional testing<\/span><\/h3>\n<p>Long ago I was involved with a project in which management invested a significant amount of time and training in an attempt to implement automated testing. The chosen tool was Rational Robot (now an IBM product). The idea behind tools such as Robot was that a test creator could record test macros, note points of verification, and replay the macros later with test results noted. Tools such as Rational Robot and WinRunner attempted to replace the human tester with record scripts. These automated scripts could be written using a scripting language or, more commonly, by recording mouse movements, clicks, and keyboard actions. In this regard, these tools of test automation allowed black-box testing through a user interface.\n<\/p><p>In this over-simplified view of automated testing, there were simply too many logistical problems with test implementation to make them practical. Any minor changes to the user interface would result in a broken test script. Those responsible for maintaining these automated scripts often found themselves spending more time maintaining the tests than using them for actual application testing.\n<\/p><p>Rational Robot and tools like it are alive and well, but I refer to them in the past tense because such tools, in my experience, have proven themselves to be a failure. I say this because I have personally spent significant amounts of time creating automated scripts in such tools, and I have been frustrated to learn later that they would not be used because of the substantial amount of interface code that changes as a project progresses. Such changes are absolutely expected, and yet, a recorded automated test does not lend itself well to an iterative development environment or an ongoing project.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Automating_functional_tests_using_unit_test_framework\">Automating functional tests using unit test framework<\/span><\/h3>\n<p>Most software projects, especially in any kind of Agile environment, undergo frequent changes and refactoring. If the traditional single-flow waterfall model worked, recorded test scripts such as those noted previously would probably work just fine as well, albeit with little benefit.\n<\/p><p>But it should be well known by know that the traditional single-flow waterfall model has failed, and we live in an iterative\/Agile world. As such, our automated tests must be equally equipped for ongoing change. And because the functional unit tests are closely related to requirements at both a white-box and black-box level, developers, not testers, have an integral role in the creation of automated tests.\n<\/p><p>To achieve this level of unit testing, a test framework must be in place. This requires a bit of up-front effort, and the details of creating such a framework go well beyond the scope of this article. Additionally, the needs of a test framework will vary depending on the project.\n<\/p><p>Test fixtures become an important part of complex functional unit testing. A test fixture is a class that incorporates all of the setup necessary for running such unit tests. It provides methods that can create common objects (for example, test servers and mock interfaces). The details included in a test fixture are specific to each project, but some common methods include test setup, simulation, and mock object creation and destruction, as well as declaration of any common functionality to be used across unit tests. To provide further detail on test fixture creation would require much more detail than can be provided here.\n<\/p><p>Given what may seem like extreme overhead in the creation of complex unit tests, we may begin to question the value. There is, no doubt, a significant up-front cost to the creation of a versatile and useful unit test framework (including a test fixture, which includes all the necessary objects and setup needed to simulate a running environment for the sake of testing). And given the fact that manual function and user acceptance testing remains a project necessity, it seems like there may be an overlap of effort.\n<\/p><p>But this is not the case.\n<\/p><p>With a little up-front creation of a solid unit test framework, we can make efforts to create unit tests simple. We can even go as far as requiring a unit test for any functional requirement implementation prior to allowing that requirement (or ticket) to be considered complete. Furthermore, as we discover potential functionality problems, we have the opportunity to introduce a new test right then and there!\nThe hardware system, software program, and general quality assurance system controls discussed below are essential in the automated manufacture of medical devices. The systematic validation of software and associated equipment will assure compliance with the QS regulation and reduce confusion, increase employee morale, reduce costs, and improve quality. Further, proper validation will smooth the integration of automated production and quality assurance equipment into manufacturing operations. Medical devices and the manufacturing processes used to produce them vary from the simple to the very complex. Thus, the QS regulation needs to be and is a flexible quality system. This flexibility is increasingly valuable as more device manufacturers move to automated production, test\/inspection, and record-keeping systems.<sup id=\"rdp-ebb-cite_ref-FDAGen02_2-0\" class=\"reference\"><a href=\"#cite_note-FDAGen02-2\" rel=\"external_link\">[2]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"What_is_a_good_unit_test.3F\">What is a good unit test?<\/span><\/h3>\n<p>In his book <i>Safe and Sound Software<\/i>, Thomas H. Faris describes the unit test as such:\n<\/p>\n<blockquote>Software testing may occur on software modules or units as they are completed. Unit testing is effective for testing units as they are completed, when other units are components have not yet been completed. Testing still remains to be completed to ensure that the application will work as intended when all software units or components are executed together.<sup id=\"rdp-ebb-cite_ref-FarisSafe06_3-0\" class=\"reference\"><a href=\"#cite_note-FarisSafe06-3\" rel=\"external_link\">[3]<\/a><\/sup><\/blockquote>\n<p>This is a start, but unit tests can achieve so much more! Faris goes on to describe a number of different categories of software<sup id=\"rdp-ebb-cite_ref-FarisSafe06_3-1\" class=\"reference\"><a href=\"#cite_note-FarisSafe06-3\" rel=\"external_link\">[3]<\/a><\/sup>:\n<\/p>\n<ul><li> Black box test<\/li>\n<li> Unit test<\/li>\n<li> Integration test<\/li>\n<li> System test<\/li>\n<li> Load test<\/li>\n<li> Regression test<\/li>\n<li> Requirements-based test<\/li>\n<li> Code-based test<\/li>\n<li> Risk-based test<\/li>\n<li> Clinical test<\/li><\/ul>\n<p>Traditionally this may be considered a fair list. Used wisely, and with the proper frame work, however, we can perform black box, integration, system, load, regression, requirements, code-based, risk-based, and clinical tests with efficient unit tests that simulate a true production environment. The purpose of this article is not to go into the technical details of how (to explain unit test frameworks, fixtures, mock objects and simulations would require much more space). Rather, I simply want to point out the benefits that result. To achieve these benefits, your software team will need to develop a deep understand of unit tests. It will take some time, but it will be time very well spent.\n<\/p><p>It\u2019s a good idea to have unit tests that go above and beyond what we traditionally think of as unit tests, and go several steps further, automating functional testing. This is another one of those areas where team members often (incorrectly) feel that there is not sufficient time to do all the work. As Harris goes on to state:\n<\/p>\n<blockquote>Software testing and defect resolution are very time-consuming, often draining more than one-half of all effort undertaken by a software organization ... Testing need not wait until the entire product is completed; iteratively designed and developed code may be tested as each iteration of code is completed. Prior to beginning of verification or validation, the project plan or other test plan document should discuss the overall strategy, including types of tests to be performed, specific functional tests to be performed, and a designation of test objectives to determine when the product is sufficiently prepared for release and distribution.<sup id=\"rdp-ebb-cite_ref-FarisSafe06_3-2\" class=\"reference\"><a href=\"#cite_note-FarisSafe06-3\" rel=\"external_link\">[3]<\/a><\/sup><\/blockquote>\n<p>Harris is touching on something that is very important in our FDA-regulated environment, and this is the fact that we must document and describe our tests. For our unit tests to be useful we must provide documentation of what each test does (that is, what specifically it is testing) and what the results are. The beauty of unit tests and the tools available (incorporation into our continuous integration environment) is that this process is streamlined in a way that makes the traceability and re-creation of test conditions required for our 510(k) extremely easy!\n<\/p><p>To achieve all of this we will need to have a testing framework capable of application launch, simulations, mock objects, mock interfaces and temporary data persistence. This all sounds like much more overhead than it actually is, but fear not: the benefits far outweigh the costs.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"What_is_the_value_of_unit_testing.3F\">What is the value of unit testing?<\/span><\/h2>\n<h3><span class=\"mw-headline\" id=\"Immediate_feedback_within_continuous_integration:_Developer_confidence\">Immediate feedback within continuous integration: Developer confidence<\/span><\/h3>\n<p>Too often we view testing as an activity that occurs only at specific times during software development. At worst, software testing takes place upon completion of development (which is when it is learned that development is nowhere near complete). In other more zealous environments, it may take place at the end of each iteration. We can do better! How about complex unit tests performing validation continuously, with each code change? It is possible to perform full regression tests with every single code change. It sounds like a significant amount of overhead, but it is not. The real cost to a project is not inattention to complex functional unit tests; the danger is that we put off testing until it is too late to react to a critical issue discovered during some predetermined testing phase.\n<\/p><p>The most effective way of killing a project is to organize it so that testing becomes an activity that is so critical to its success that we do not allow for the possibility that testing can do what it is supposed to do: discover a defect prior to go-live.\n<\/p><p>At its most basic level, a continuous integration build environment does just one thing: it runs whatever scripts we tell it to. To that end, it is important that the CI build execute unit tests and that a failure of any single unit test is considered a failure of the continuous integration build. The power of a tool such as Jenkins is that we can tell it to run whatever we want, log the outcome, keep build artifacts, run third-party evaluation tools, and report on results. With integration of our software version control system (e.g., Subversion, Git, Mercurial, CVS, etc.), we know the changeset relevant to a particular build. It can be configured to generate a build at whatever interval we want (nightly, hourly, every time there is a code commit, etc.). When a test fails, we know immediately what changeset was involved.\n<\/p><p>Personally, every time I do any code commit of significance, one of the first things I do is check the CI build for success. If I've broken the build, I get to work on correcting the problem (and if I cannot correct the problem quickly, I roll my changeset out so that the CI build continues to work until I\u2019ve fixed the issue).\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Easy_refactoring\">Easy refactoring<\/span><\/h4>\n<p>As a developer, refactoring can be a scary thing. Refactoring is perhaps the most effective way of introducing a serious defect while doing something that seems innocuous. With thorough unit tests performing a full regression test with each and every committed software changeset, however, a developer can have confidence that his or her simple code changes have not introduced a defect. We have continuous integration builds running our tests for many reasons, not the least of which is to alert developers to the possibility that their changes have broken the build.\n<\/p><p>As a developer I strive to avoid breaking the continuous integration build. When I do break it, however, I am very pleased to know that what was done to cause a problem has been discovered immediately. Correction of a defect becomes much more costly when its discovery is not noticed until the end of a development phase!\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Regression_tests_with_every_code_change\">Regression tests with every code change<\/span><\/h4>\n<p>By \"repeated\" I mean something different than repeatable. The fundamental benefit with repeated tests is the fact that a test can be executed many more times by automation than by a human tester. Sometimes, even without a related code change, and much to our surprise, we see a test suddenly fail where it succeeded numerous times before. What happened?\n<\/p><p>The most difficult software defects to fix (much less, find) are the ones that do not happen consistently. Database locking issues, memory issues, deadlock bugs, memory leaks, and race conditions can result in such defects. These defects are serious, but if we never detect them, how can we fix them?\n<\/p><p>As stated previously, it is imperative that have unit tests that go above and beyond what we traditionally think of as unit tests, going several steps further, automating functional testing). This is another one of those areas where team members often (incorrectly) feel that there is not sufficient time to deal with the creation of unit tests. Given a proper framework, however, creation of unit tests need not be overwhelming.\n<\/p><p>Another occasional issue has to do with misuse of the software version control system. Many developers know the frustration that can come with an accidental code change resulting from one developer stepping over the modifications of another. While this is a rare issue in a properly used version control environment, it does still happen, and unit tests can quickly reveal such a problem at build time.\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Concurrency_tests\">Concurrency tests<\/span><\/h4>\n<p>Concurrency tests are tricky, and it is in concurrency testing that the repeated and rapid nature of functional unit tests can shine where human testers cannot. I personally have witnessed many occasions in which a CI build suddenly fails for no obvious reason. There was no code commit related to the particular point-of-failure, and yet a unit test that once succeeded suddenly fails? Why?\n<\/p><p>This can happen (and it does happen) because concurrency problems, by their very nature, are hit or miss. Sometimes they are so unlikely to occur that we never witness them during the course of normal testing. When a continuous integration environment runs concurrency tests dozens of times a day, however, we increase the likelihood of finding a hidden and menacing problem. Additionally, unit tests can simulate many concurrent users and processes in a way that even a team of human testers cannot.\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Repeatable_and_traceable_test_results\">Repeatable and traceable test results<\/span><\/h4>\n<p>This is the key to making our unit tests adhere to the standards we have set forth in our quality system so that we may use them as a part of our submission (see the following section on Regulated Environment Needs). If we are going to put forth the effort, and since we already know that unit tests result in a quality improvement to our software, why wouldn\u2019t we want to include these test results?\n<\/p><p>Our continuous integration server can and should be used to store our unit test results right alongside each and every build that it performs.\n<\/p><p>This is a benefit not only in the world of an FDA-regulated environment, of course. In any software project it can be difficult to recreate conditions under which a defect was discovered. With a CI build executing our build and test scripts under a known environment with a known set of files (the CI build tool pulls from the version control system), it is possible to execute the tests under exact and specific circumstances.\n<\/p><p>Many of the benefits of functional unit testing listed above are gained only when unit tests are written alongside design and development (test-driven methodologies aside). It is imperative that the development team develop and observe test results while design and activities take place. This is of benefit to the quality assurance team as well, as Dean Leffingwell notes:\n<\/p>\n<blockquote>A comprehensive unit test strategy prevents QA and test personnel from spending most of their time finding and reporting on code-level bugs and allows the team to move its focus to more system-level testing challenges. Indeed, for many agile teams, the addition of a comprehensive unit test strategy is a key pivot point in their move toward true agility \u2014 and one that delivers \"best bang for the buck\" in determining overall system quality.<sup id=\"rdp-ebb-cite_ref-LeffingwellAgile11_2_4-0\" class=\"reference\"><a href=\"#cite_note-LeffingwellAgile11_2-4\" rel=\"external_link\">[4]<\/a><\/sup> Also, it is probably becoming clear that a key benefit of functional unit tests is the real-time feedback offered to the development team. Humble and Farley refer to the unit tests that are executed with each software change as \"commit tests.\"<sup id=\"rdp-ebb-cite_ref-HumbleCont10_5-0\" class=\"reference\"><a href=\"#cite_note-HumbleCont10-5\" rel=\"external_link\">[5]<\/a><\/sup><\/blockquote>\n<p>Commit tests that run against every check-in provide us with timely feedback on problems with the latest build and on bugs in our application in the small.<sup id=\"rdp-ebb-cite_ref-HumbleCont10_5-1\" class=\"reference\"><a href=\"#cite_note-HumbleCont10-5\" rel=\"external_link\">[5]<\/a><\/sup> Project unit tests, which should offer significant amount coverage (at least 80 percent), provide the team with built-in software change-commit acceptance criteria. If a developer causes the CI build to fail because of a code change, it is immediately known that the change involved does not meet minimum accepted criteria, and it requires urgent attention.\n<\/p><p>Humble and Farley continue:\n<\/p>\n<blockquote>Crucially, the development team must respond immediately to accepted test breakages that occur as part of the normal development process. They must decided if the breakage is a result of a regression that has been introduced, an intentional change in the behavior of the application, or a problem with the test. Then they must take appropriate action to get the automated acceptance test suite passing again.<sup id=\"rdp-ebb-cite_ref-HumbleCont10_5-2\" class=\"reference\"><a href=\"#cite_note-HumbleCont10-5\" rel=\"external_link\">[5]<\/a><\/sup><\/blockquote>\n<h4><span class=\"mw-headline\" id=\"Regulated_environment_needs\">Regulated environment needs<\/span><\/h4>\n<p>Per 21 CFR Part 820.30 on design controls:\n<\/p>\n<blockquote>(f) <i>Design verification<\/i>. Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results of the design verification, including identification of the design, method(s), the date, and the individual(s) performing the verification, shall be documented in the design history file (DHF).<sup id=\"rdp-ebb-cite_ref-21CFRPart820.30_6-0\" class=\"reference\"><a href=\"#cite_note-21CFRPart820.30-6\" rel=\"external_link\">[6]<\/a><\/sup><\/blockquote>\n<p>Simply put, our functional unit tests must be a part of our DHF, and we must document each test and test result (success or failure) as well as tie tests and outcomes to specific software releases. This is made extremely easy with a continuous integration environment in which builds and build outcomes (including test results) are stored on a server, labeled, and linked to from our DHF. Indeed, what is sometimes a tedious task when it comes to manual execution and documentation of test results becomes quite convenient.\n<\/p><p>The same is true of design validation:\n<\/p>\n<blockquote>(g) <i>Design validation<\/i>. Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall ensure that devices conform to defined user needs and intended uses and shall include testing of production units under actual or simulated use conditions. Design validation shall include software validation and risk analysis, where appropriate. The results of the design validation, including identification of the design, method(s), the date, and the individual(s) performing the validation, shall be documented in the DHF.<sup id=\"rdp-ebb-cite_ref-21CFRPart820.30_6-1\" class=\"reference\"><a href=\"#cite_note-21CFRPart820.30-6\" rel=\"external_link\">[6]<\/a><\/sup><\/blockquote>\n<p>Because our CI environment packages build and test conditions at a given point in time, we can successfully satisfy the requirements laid out by 21 CFR Part 820.30 (f) and (g) with very little effort. We simply allow our CI environment to do that which is does best, and that which a human tester may spend many hours attempting to do with accuracy.\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Document_the_approach\">Document the approach<\/span><\/h4>\n<p>As discussed, all these tests are indeed very helpful to the creation of good software. However, without a wise approach to incorporation of such tests in our FDA-regulated environment, they are of little use in any auditable capacity. It is necessary to document our approach to unit test usage and documentation within our standard operating procedures (SOPs) and work instructions, and this is to be documented in much the same way that we would document any manual verification and validation test activities.\n<\/p><p>To this end, it is necessary to make our unit tests and their outputs an integral part of our DHF. Each test must be traceable, and this means that unit tests are given unique identifiers. These unique identifiers are very easily assigned using an approach in which we organize tests in logical units (for example, by functional area) and label tests sequentially.\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Label_and_trace_tests\">Label and trace tests<\/span><\/h4>\n<p>An approach that I have taken in the past is to assign some high-level numeric identifier and a secondary sub-identifier that is used for the specific test. For example, we may have the following functional areas: user session, audit log, data input, data output, and web user interface tests (these are very generic examples of functional areas, granted). Given such functional areas, I would label each test using test naming annotations, with the following high level identifiers:\n<\/p>\n<ul><li> 1000: user session tests<\/li>\n<li> 2000: audit log tests<\/li>\n<li> 3000: data input tests<\/li>\n<li> 4000: data output tests<\/li>\n<li> 5000: web user interface tests<\/li><\/ul>\n<p>Within each test it is then necessary to go a step further, applying some sequential identifier to each test. For example, the user test package may include tests for functional requirements such as user login, user logout, session expiration, and a multiple-user login concurrency test. In such a scenario, we would label the tests as follows:\n<\/p>\n<ul><li> 1000_010: user login<\/li>\n<li> 1000_020: user logout<\/li>\n<li> 1000_030: session expiration<\/li>\n<li> 1000_040: multiple concurrent user login<\/li><\/ul>\n<p>Using TestNG syntax, along with proper Javadoc comments, it is very easy to label and describe a test such that inclusion in our DHF is indeed very simple.\n<\/p>\n<div class=\"mw-highlight mw-content-ltr\" dir=\"ltr\"><pre>\/** * Test basic user login and session creation with a valid user. * * @throws Exception *\/@Test(dependsOnMethods = {\"testActivePatientIntegrationDisabled\"}, groups = {\"TS0005_AUTO_VE1023\"})public void testActivePatientIntegrationEnabled() throws Exception { Fixture myApp new Fixture(); UserSession mySession = fixture.login(\u201ctest_user\u201d, \u201ctest_password\u201d); assertNotNull(mySession); asertTrue(mySession.active());}<\/pre><\/div>\n<p>Any numbering we choose to use for these tests is fine, as long as we document our approach to test labeling in some project level document, for example a validation plan or master test plan. Such decisions are left to those who design and apply a quality system for the FDA-regulated project. As most of us know by now, the FDA doesn\u2019t tell us exactly how we are to do things; rather, we are simply told that we must create a good quality system, trace our requirements through design, incorporate the history in our DHF, and recreate build and test conditions.\n<\/p><p>If I make this all sound a little too easy, it is because I believe it is easy. Too often we view cGMP guidance as a terrible hindrance to productivity, but we are in control of making things as efficient as we can.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"The_traceability_matrix\">The traceability matrix<\/span><\/h2>\n<p>A critical factor in making unit tests usable in an auditable manner is incorporating them into the traceability matrix. As with any test, requirements, design elements, and hazards must be traced to one another through use of the traceability matrix.\n<\/p>\n<blockquote>The project team must document traceability of requirements through specification and testing to ensure that all requirements have been tested and correctly implemented (product requirements traceability matrix).<sup id=\"rdp-ebb-cite_ref-FarisSafe06_3-3\" class=\"reference\"><a href=\"#cite_note-FarisSafe06-3\" rel=\"external_link\">[3]<\/a><\/sup><\/blockquote>\n<p>With each automated test labeled, we can use the built-in JUnit or TestNG funcationality (along with XSLT, if we so choose) to create output that is tied to the build number and changset and traceable within our trace matrix. The output of our tests (which are run during each continuous integration build) may be as follows:\n<\/p>\n<div class=\"mw-highlight mw-content-ltr\" dir=\"ltr\"><pre>TEST NAME STATUSTS0005_AUTO_VE1022 PASSTS0005_AUTO_VE1023 PASS TS0005_AUTO_VE1024 FAILTS0005_AUTO_VE1025 SKIP\u2026<\/pre><\/div>\n<p>Naturally, we hope that all the automated tests pass, but when they fail we need to record the failure. Its my opinion that placing all test outcomes in the DHF is not necessary. Rather, the DHF can point to the continuous integration build server, where automated test results are bundled alongside each build. Finally, at the end of a sprint or iteration, the appropriate test results for the final locked down build are captured in the DHF and traced appropriately per SOPs.\n<\/p><p>Our SOPs and work instructions will require that we prove traceability of our tests and test results, whether manual or automated unit tests. Just as has always been done with the manual tests that we are familiar with, tests must be traced to software requirements, design specifications, hazards, and risks. The goal is simply to prove that we have tested that which we have designed and implemented, and in the case of automated tests, this is all very easy to achieve!\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Do_we_still_need_manual_tests.3F\">Do we still need manual tests?<\/span><\/h3>\n<p>Yes! Absolutely! There are a number of reasons why manual tests are still, and always will be, required. Take for example installation qualification and environmental tests. Both manual and automated tests are valid and valuable, and neither should be considered a replacement for the other.\n<\/p><p>I recall being a child in karate lessons. One day I came home from a lesson, very proud that I had learned to block a punch. \"Come at me with a punch,\" I said to my friend.\n<\/p><p>Doing what I asked, he punched me right in the chest, and I failed to block the punch. This punch wasn't thrown the way I expected (the way we practiced in karate lessons).\n<\/p><p>\"No, no, no! You\u2019re punching me the wrong way!\" I said. I only knew how to block one kind of punch, and when punched a different way, my block no longer worked. To me, this karate lesson highlights the difference between an exception and an error. Automated tests can provide error test coverage very well. But when thrown something unanticipated, they don\u2019t offer the creativity in and of themselves to find the issue.\n<\/p><p>It is up to us, developers and testers, to come up with creative punches to throw at our system. This is where manual testing allows a certain amount of \"creative\" punching that may not be considered during unit test development. Manual tests also lead to greater insight related to usability and user interaction issues.\n<\/p><p>Perhaps even more importantly, manual tests give feedback on general application usability and user interaction. To this end, a defect that is discovered during manual testing should result in an automated test.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Notes\">Notes<\/span><\/h2>\n<p>The original author had anticipated writing about the following sub-topics but never did: test fixture, mock objects, avoiding the Singleton design pattern, in-memory DB, and in-memory servlet container.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-LeffingwellAgile11_1-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-LeffingwellAgile11_1_1-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation book\">Leffingwell, D. (2011). <i>Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise<\/i>. Addison-Wesley Professional. p. 61. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 9780321635846.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Agile+Software+Requirements%3A+Lean+Requirements+Practices+for+Teams%2C+Programs%2C+and+the+Enterprise&rft.aulast=Leffingwell%2C+D.&rft.au=Leffingwell%2C+D.&rft.date=2011&rft.pages=p.%26nbsp%3B61&rft.pub=Addison-Wesley+Professional&rft.isbn=9780321635846&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FDAGen02-2\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FDAGen02_2-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/GuidanceDocuments\/ucm085281.htm\" target=\"_blank\">\"General Principles of Software Validation; Final Guidance for Industry and FDA Staff\"<\/a>. Food and Drug Administration. 11 January 2002<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/GuidanceDocuments\/ucm085281.htm\" target=\"_blank\">http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/GuidanceDocuments\/ucm085281.htm<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=General+Principles+of+Software+Validation%3B+Final+Guidance+for+Industry+and+FDA+Staff&rft.atitle=&rft.date=11+January+2002&rft.pub=Food+and+Drug+Administration&rft_id=http%3A%2F%2Fwww.fda.gov%2FMedicalDevices%2FDeviceRegulationandGuidance%2FGuidanceDocuments%2Fucm085281.htm&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FarisSafe06-3\"><span class=\"mw-cite-backlink\">\u2191 <sup><a href=\"#cite_ref-FarisSafe06_3-0\" rel=\"external_link\">3.0<\/a><\/sup> <sup><a href=\"#cite_ref-FarisSafe06_3-1\" rel=\"external_link\">3.1<\/a><\/sup> <sup><a href=\"#cite_ref-FarisSafe06_3-2\" rel=\"external_link\">3.2<\/a><\/sup> <sup><a href=\"#cite_ref-FarisSafe06_3-3\" rel=\"external_link\">3.3<\/a><\/sup><\/span> <span class=\"reference-text\"><span class=\"citation book\">Faris, T.H. (2006). <i>Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations<\/i>. ASQ Quality Press. p. 118\u2013123. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 0873896742.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Safe+and+Sound+Software%3A+Creating+an+Efficient+and+Effective+Quality+System+for+Software+Medical+Device+Organizations&rft.aulast=Faris%2C+T.H.&rft.au=Faris%2C+T.H.&rft.date=2006&rft.pages=p.%26nbsp%3B118%E2%80%93123&rft.pub=ASQ+Quality+Press&rft.isbn=0873896742&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-LeffingwellAgile11_2-4\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-LeffingwellAgile11_2_4-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation book\">Leffingwell, D. (2011). <i>Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise<\/i>. Addison-Wesley Professional. p. 196. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 9780321635846.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Agile+Software+Requirements%3A+Lean+Requirements+Practices+for+Teams%2C+Programs%2C+and+the+Enterprise&rft.aulast=Leffingwell%2C+D.&rft.au=Leffingwell%2C+D.&rft.date=2011&rft.pages=p.%26nbsp%3B196&rft.pub=Addison-Wesley+Professional&rft.isbn=9780321635846&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-HumbleCont10-5\"><span class=\"mw-cite-backlink\">\u2191 <sup><a href=\"#cite_ref-HumbleCont10_5-0\" rel=\"external_link\">5.0<\/a><\/sup> <sup><a href=\"#cite_ref-HumbleCont10_5-1\" rel=\"external_link\">5.1<\/a><\/sup> <sup><a href=\"#cite_ref-HumbleCont10_5-2\" rel=\"external_link\">5.2<\/a><\/sup><\/span> <span class=\"reference-text\"><span class=\"citation book\">Humble, J.; Farley, D. (2010). <i>Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation<\/i>. Addison-Wesley Professional. p. 124. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 9780321601912.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Continuous+Delivery%3A+Reliable+Software+Releases+through+Build%2C+Test%2C+and+Deployment+Automation&rft.aulast=Humble%2C+J.%3B+Farley%2C+D.&rft.au=Humble%2C+J.%3B+Farley%2C+D.&rft.date=2010&rft.pages=p.%26nbsp%3B124&rft.pub=Addison-Wesley+Professional&rft.isbn=9780321601912&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-21CFRPart820.30-6\"><span class=\"mw-cite-backlink\">\u2191 <sup><a href=\"#cite_ref-21CFRPart820.30_6-0\" rel=\"external_link\">6.0<\/a><\/sup> <sup><a href=\"#cite_ref-21CFRPart820.30_6-1\" rel=\"external_link\">6.1<\/a><\/sup><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30\" target=\"_blank\">\"Title 21--Food and Drugs, Part 820--Quality System Regulation, Sec. 820.30 Design controls\"<\/a>. <i>CFR - Code of Federal Regulations Title 21<\/i>. Food and Drug Administration. 21 August 2015<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30\" target=\"_blank\">https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Title+21--Food+and+Drugs%2C+Part+820--Quality+System+Regulation%2C+Sec.+820.30+Design+controls&rft.atitle=CFR+-+Code+of+Federal+Regulations+Title+21&rft.date=21+August+2015&rft.pub=Food+and+Drug+Administration&rft_id=https%3A%2F%2Fwww.accessdata.fda.gov%2Fscripts%2Fcdrh%2Fcfdocs%2FcfCFR%2FCFRSearch.cfm%3Ffr%3D820.30&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<\/ol><\/div>\n\n<!-- \nNewPP limit report\nCached time: 20190104224854\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.195 seconds\nReal time usage: 0.236 seconds\nPreprocessor visited node count: 4042\/1000000\nPreprocessor generated node count: 16965\/1000000\nPost\u2010expand include size: 25909\/2097152 bytes\nTemplate argument size: 8828\/2097152 bytes\nHighest expansion depth: 13\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 166.874 1 - -total\n100.00% 166.874 1 - Template:Reflist\n 78.42% 130.861 6 - Template:Citation\/core\n 64.89% 108.290 4 - Template:Cite_book\n 22.18% 37.016 2 - Template:Cite_web\n 7.40% 12.349 4 - Template:Citation\/identifier\n 4.23% 7.058 7 - Template:Citation\/make_link\n 2.08% 3.477 8 - Template:Hide_in_print\n 1.92% 3.203 4 - Template:Only_in_print\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8686-0!*!0!!en!*!* and timestamp 20190104224854 and revision id 25245\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","fe175ec1d1846bbf56d90860f4b8b11a_images":[],"fe175ec1d1846bbf56d90860f4b8b11a_timestamp":1546642134,"216ba38dff8063ab9365f6477c058f2c_type":"article","216ba38dff8063ab9365f6477c058f2c_title":"Version control","216ba38dff8063ab9365f6477c058f2c_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control","216ba38dff8063ab9365f6477c058f2c_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Version Control\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\nVersion control \nThe earliest phase of any software project is the planning phase. At this stage, people involved with the project have meetings and discuss some very high level needs. There are probably some presentations and documents that are created. Project management plans have not been developed, but they should be thought about. And as I stated previously, we begin creation of our work instructions (the application of our SOPs) in this stage.\nThe design history file (DHF) of a project must contain all of the historical \"stuff\" that goes into the project, so even at this early stage it is necessary to decide on a version control system and create a repository. Sure, there may be no tracing involved yet, but this early \"stuff\" should still be kept around In the DHF. Because the earliest phases of the software project result in outputs that are to be included in the DHF, it is necessary determine the version control tool and establish the version control repository early on (for the sake of this article, I assume a basic understanding of version control\/revision control systems).\n\nProject traceability \nTracing is everything, and Subversion, with its changesets, lends itself extremely well to integration with other tools used throughout the project. When used with your issue tracking software, every issue can be linked directly with a set of items in the repository that are related to addressing and resolving that issue. With a click of the mouse we can see a list of all the project file modifications related to a single issue.\nI recommend using a single version control system and repository for all of the \"stuff\" that goes into a project (there are many good reasons to use a repository-per-project approach as well). This means that project management plans, documents, presentations, code, test data, and results should all go into the same repository, and the repository itself is laid out so that each project has its own trunk, tags, and branches. If documents are stored in a separate repository (or in a different version control system altogether) and software code is stored in a different repository, we lose much of the project traceability that we could have.\n(Note: When placing binaries in a version control system, there is no merge path as with text file source code. This means it is generally a good practice for team members, when editing documents, to place a strict lock on the file while editing. This can be done in Subversion.[1] Strict file locking allows others to be notified that another user is currently working on a file.)\nWhile a clear benefit of this approach is the fact that all of the \"stuff\" of a project is associated with the same repository, some may view this as a problem with the setup. I suggest this setup only because I am thinking specifically in terms of an FDA-regulated software product in which it is beneficial to relate all elements of the project in a single traceable repository. In this setup documentation will be versioned (and tagged) along with project source code, and this may or may not be desirable depending on project needs.\nSubversion is superior to many of its predecessors because of (among other things) its introduction to \"changesets.\" A changeset provides a snapshot in time of the entire project repository. When documents, presentations, or source code are changed and committed to the repository, a new changeset number is created. Now, at any time in the future, we can checkout all items in the repository tree as of that changeset. When asked what version of a product something was changed in, we can pull everything relevant to the project at the point of that change. No longer do we have to tag or label our repository in order to revisit a particular instance in time (although Subversion still allows tagging). Every single commit to the repository effectively results in a \"tag.\"\nThis is not to say that tagging is no longer useful. On the contrary, it remains very useful. All software releases, included internal releases, should be tagged (and our work instructions should tell us when and how to perform tagging).\nAnother advantage of Subversion is that, unlike some of its predecessors, it allows for the control and history of directories as well as files (including file and directory name changes). The most commonly used predecessor to Subversion, CVS, did not maintain a version history of a file or directory that was renamed. Subversion can handle the renaming of any version-controlled object.\n\nReferences \n\n\n\u2191 K\u00fcng, S.; Onken, L.; Large, S. (20 August 2015). \"Chapter 4. Daily Use Guide: Locking\". TortoiseSVN: A Subversion client for Windows. https:\/\/tortoisesvn.net\/docs\/nightly\/TortoiseSVN_en\/tsvn-dug-locking.html . Retrieved 27 April 2016 .   \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 21:18.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 331 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","216ba38dff8063ab9365f6477c058f2c_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Version_Control skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Version Control<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n<h2><span class=\"mw-headline\" id=\"Version_control\">Version control<\/span><\/h2>\n<p>The earliest phase of any software project is the planning phase. At this stage, people involved with the project have meetings and discuss some very high level needs. There are probably some presentations and documents that are created. Project management plans have not been developed, but they should be thought about. And as I stated previously, we begin creation of our work instructions (the application of our SOPs) in this stage.\n<\/p><p>The design history file (DHF) of a project must contain all of the historical \"stuff\" that goes into the project, so even at this early stage it is necessary to decide on a version control system and create a repository. Sure, there may be no tracing involved yet, but this early \"stuff\" should still be kept around In the DHF. Because the earliest phases of the software project result in outputs that are to be included in the DHF, it is necessary determine the version control tool and establish the version control repository early on (for the sake of this article, I assume a basic understanding of version control\/revision control systems).\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Project_traceability\">Project traceability<\/span><\/h2>\n<p>Tracing is everything, and Subversion, with its changesets, lends itself extremely well to integration with other tools used throughout the project. When used with your issue tracking software, every issue can be linked directly with a set of items in the repository that are related to addressing and resolving that issue. With a click of the mouse we can see a list of all the project file modifications related to a single issue.\n<\/p><p>I recommend using a single version control system and repository for all of the \"stuff\" that goes into a project (there are many good reasons to use a repository-per-project approach as well). This means that project management plans, documents, presentations, code, test data, and results should all go into the same repository, and the repository itself is laid out so that each project has its own trunk, tags, and branches. If documents are stored in a separate repository (or in a different version control system altogether) and software code is stored in a different repository, we lose much of the project traceability that we could have.\n<\/p><p>(Note: When placing binaries in a version control system, there is no merge path as with text file source code. This means it is generally a good practice for team members, when editing documents, to place a strict lock on the file while editing. This can be done in Subversion.<sup id=\"rdp-ebb-cite_ref-K.C3.BCngTort15_1-0\" class=\"reference\"><a href=\"#cite_note-K.C3.BCngTort15-1\" rel=\"external_link\">[1]<\/a><\/sup> Strict file locking allows others to be notified that another user is currently working on a file.)\n<\/p><p>While a clear benefit of this approach is the fact that all of the \"stuff\" of a project is associated with the same repository, some may view this as a problem with the setup. I suggest this setup only because I am thinking specifically in terms of an FDA-regulated software product in which it is beneficial to relate all elements of the project in a single traceable repository. In this setup documentation will be versioned (and tagged) along with project source code, and this may or may not be desirable depending on project needs.\n<\/p><p>Subversion is superior to many of its predecessors because of (among other things) its introduction to \"changesets.\" A changeset provides a snapshot in time of the entire project repository. When documents, presentations, or source code are changed and committed to the repository, a new changeset number is created. Now, at any time in the future, we can checkout all items in the repository tree as of that changeset. When asked what version of a product something was changed in, we can pull everything relevant to the project at the point of that change. No longer do we have to tag or label our repository in order to revisit a particular instance in time (although Subversion still allows tagging). Every single commit to the repository effectively results in a \"tag.\"\n<\/p><p>This is not to say that tagging is no longer useful. On the contrary, it remains very useful. All software releases, included internal releases, should be tagged (and our work instructions should tell us when and how to perform tagging).\n<\/p><p>Another advantage of Subversion is that, unlike some of its predecessors, it allows for the control and history of directories as well as files (including file and directory name changes). The most commonly used predecessor to Subversion, CVS, did not maintain a version history of a file or directory that was renamed. Subversion can handle the renaming of any version-controlled object.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-K.C3.BCngTort15-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-K.C3.BCngTort15_1-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">K\u00fcng, S.; Onken, L.; Large, S. (20 August 2015). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/tortoisesvn.net\/docs\/nightly\/TortoiseSVN_en\/tsvn-dug-locking.html\" target=\"_blank\">\"Chapter 4. Daily Use Guide: Locking\"<\/a>. <i>TortoiseSVN: A Subversion client for Windows<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/tortoisesvn.net\/docs\/nightly\/TortoiseSVN_en\/tsvn-dug-locking.html\" target=\"_blank\">https:\/\/tortoisesvn.net\/docs\/nightly\/TortoiseSVN_en\/tsvn-dug-locking.html<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Chapter+4.+Daily+Use+Guide%3A+Locking&rft.atitle=TortoiseSVN%3A+A+Subversion+client+for+Windows&rft.aulast=K%C3%BCng%2C+S.%3B+Onken%2C+L.%3B+Large%2C+S.&rft.au=K%C3%BCng%2C+S.%3B+Onken%2C+L.%3B+Large%2C+S.&rft.date=20+August+2015&rft_id=https%3A%2F%2Ftortoisesvn.net%2Fdocs%2Fnightly%2FTortoiseSVN_en%2Ftsvn-dug-locking.html&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<\/ol><\/div>\n\n<!-- \nNewPP limit report\nCached time: 20190104224854\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.053 seconds\nReal time usage: 0.064 seconds\nPreprocessor visited node count: 663\/1000000\nPreprocessor generated node count: 11529\/1000000\nPost\u2010expand include size: 4933\/2097152 bytes\nTemplate argument size: 1933\/2097152 bytes\nHighest expansion depth: 12\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 47.486 1 - Template:Reflist\n100.00% 47.486 1 - -total\n 83.68% 39.736 1 - Template:Cite_web\n 72.59% 34.470 1 - Template:Citation\/core\n 7.42% 3.525 2 - Template:Citation\/make_link\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8685-0!*!0!!*!*!* and timestamp 20190104224854 and revision id 25243\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","216ba38dff8063ab9365f6477c058f2c_images":[],"216ba38dff8063ab9365f6477c058f2c_timestamp":1546642134,"a2777f409854379de217cacc4dde9d3a_type":"article","a2777f409854379de217cacc4dde9d3a_title":"CI theory, practices, and tools","a2777f409854379de217cacc4dde9d3a_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2","a2777f409854379de217cacc4dde9d3a_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Continuous Integration: Part 2\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\n\r\n\nNote: The following content originates from a separate source. However, it elaborates further on the original author's ideas in the previous section and adds additional information regarding benefits, drawbacks, and tools other than Jenkins, Trac, and Redmine. It has been added and slightly modified under the same license as the rest of the content.\n\nContents\n\n1 Theory \n2 Recommended practices \n\n2.1 Maintain a code repository \n2.2 Automate the build \n2.3 Make the build self-testing \n2.4 Everyone commits to the baseline every day \n2.5 Every commit (to baseline) should be built \n2.6 Keep the build fast \n2.7 Test in a clone of the production environment \n2.8 Make it easy to get the latest deliverables \n2.9 Everyone can see the results of the latest build \n2.10 Automate deployment \n\n\n3 Advantages and disadvantages \n\n3.1 Advantages \n3.2 Disadvantages \n\n\n4 Software \n5 Further reading \n6 References \n7 External links \n\n\n\nTheory \nWhen embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the code repository, this copy gradually ceases to reflect the repository code. When developers submit code to the repository, they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes.\nEventually, the repository may become so different from the developers' baselines that they enter what is sometimes called \"integration hell\",[1] where the time it takes to integrate exceeds the time it took to make their original changes. In a worst-case scenario, developers may have to discard their changes and completely redo the work.\nContinuous integration involves integrating early and often, so as to avoid the pitfalls of \"integration hell.\" The practice aims to reduce rework and thus reduce cost and time, particularly when automated as a best practice.[2][3]\n\nRecommended practices \nContinuous integration should occur frequently enough that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately.[4] Normal practice is to trigger these builds by every commit to a repository, rather than a periodically scheduled build. The practicalities of doing this in a multi-developer environment of rapid commits are such that it's usual to trigger a short timer after each commit, then to start a build when either this timer expires, or after a rather longer interval since the last build. Automated tools such as CruiseControl or Jenkins offer this scheduling automatically.\nAnother factor is the need for a version control system that supports atomic commits, i.e. all of a developer's changes may be seen as a single commit operation. There is no point in trying to build from only half of the changed files.\n\nMaintain a code repository \nThis practice advocates the use of a revision control system for the project's source code. All artifacts required to build the project should be placed in the repository. In this practice and in the revision control community, the convention is that the system should be buildable from a fresh checkout and not require additional dependencies. Extreme Programming advocate Martin Fowler also mentions that where branching is supported by tools, its use should be minimized.[4] Instead, integrating changes is preferred rather than creating multiple versions of the software that are maintained simultaneously. The mainline (or trunk) should be the place for the working version of the software.\n\nAutomate the build \nA single command should have the capability of building the system. Many build-tools, such as make, have existed for years. Other more recent tools like Ant, Maven, MSBuild or IBM Rational Build Forge are frequently used in continuous integration environments. Automation of the build should include automating the integration, which often includes deployment into a production-like environment. In many cases, the build script not only compiles binaries, but also generates documentation, website pages, statistics, and distribution media (such as Windows MSI files, RPM or DEB files).\n\nMake the build self-testing \nOnce the code is built, all tests should run to confirm that it behaves as the developers expect it to behave.\n\nEveryone commits to the baseline every day \nBy committing regularly, every committer can reduce the number of conflicting changes. Checking in a week's worth of work runs the risk of conflicting with other features and can be very difficult to resolve. Early, small conflicts in an area of the system cause team members to communicate about the change they are making.\nMany programmers recommend committing all changes at least once a day (once per feature built), and in addition performing a nightly build.\n\nEvery commit (to baseline) should be built \nThe system should build commits to the current working version in order to verify that they integrate correctly. A common practice is to use automated continuous integration, although this may be done manually. For many, continuous integration is synonymous with using automated continuous integration where a continuous integration server or daemon monitors the version control system for changes, then automatically runs the build process.\n\nKeep the build fast \nThe build needs to complete rapidly, so that if there is a problem with integration, it is quickly identified.\n\nTest in a clone of the production environment \nHaving a test environment can lead to failures in tested systems when they deploy in the production environment, because the production environment may differ from the test environment in a significant way. However, building a replica of a production environment is cost prohibitive. Instead, the pre-production environment should be built to be a scalable version of the actual production environment to both alleviate costs while maintaining technology stack composition and nuances.\n\nMake it easy to get the latest deliverables \nMaking builds readily available to stakeholders and testers can reduce the amount of rework necessary when rebuilding a feature that doesn't meet requirements. Additionally, early testing reduces the chances that defects survive until deployment. Finding errors earlier also, in some cases, reduces the amount of work necessary to resolve them.\n\nEveryone can see the results of the latest build \nIt should be easy to find out where\/whether the build breaks and who made the relevant change.\n\nAutomate deployment \nMost CI systems allow the running of scripts after a build finishes. In most situations, it is possible to write a script to deploy the application to a live test server that everyone can look at. A further advance in this way of thinking is the concept of \"continuous deployment,\" which calls for the software to be deployed directly into production, often with additional automation to prevent defects or regressions.[5][6]\n\nAdvantages and disadvantages \nAdvantages \nContinuous integration has many advantages[4]:\n\n ability to revert the codebase back to a bug-free state, without wasting time debugging, when unit tests fail or a bug emerges;\n ability to detect and fix integration problems continuously, avoiding last-minute chaos at release dates (when everyone tries to check in their slightly incompatible versions);\n early warning of broken\/incompatible code;\n early warning of conflicting changes;\n immediate unit testing of all changes;\n constant availability of a \"current\" build for testing, demo, or release purposes;\n immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing;\n modular, less complex code often a result of frequent code check-in by developers; and\n metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team.\nDisadvantages \n initial setup time required;\n well-developed test-suite required to achieve automated testing advantages;\n large-scale refactoring can be troublesome due to continuously changing code base; and\n hardware costs for build machines can be significant.\nMany teams using CI report that the advantages of CI well outweigh the disadvantages.[7] The effect of finding and fixing integration bugs early in the development process saves both time and money over the lifespan of a project.\n\nSoftware \nTo support continuous integration, software tools such as automated build software can be employed.\nSoftware tools for continuous integration include:\n\n AnthillPro \u2014 continuous integration server by Urbancode\n Apache Continuum \u2014 continuous integration server supporting Apache Maven and Apache Ant. Supports CVS, Subversion, Ant, Maven, and shell scripts\n Apache Gump \u2014 continuous integration tool by Apache\n Automated Build Studio \u2014 proprietary automated build, continuous integration and release management system by AutomatedQA\n Bamboo \u2014 proprietary continuous integration server by Atlassian Software Systems\n BuildBot \u2014 Python\/Twisted-based continuous build system\n BuildForge - proprietary automated build engine by IBM \/ Rational\n BuildMaster \u2014 proprietary application lifecycle management and continuous integration tool by Inedo\n CABIE - Continuous Automated Build and Integration Environment \u2014 open source, written in Perl; works with CVS, Subversion, AccuRev, Bazaar and Perforce\n Cascade \u2014 proprietary continuous integration tool; provides a checkpointing facility to build and test changes before they are committed\n codeBeamer \u2014 proprietary collaboration software with built-in continuous integration features\n CruiseControl \u2014 Java-based framework for a continuous build process\n CruiseControl.NET \u2014 .NET-based automated continuous integration server\n CruiseControl.rb - Lightweight, Ruby-based continuous integration server that can build any codebase, not only Ruby, released under Apache Licence 2.0\n ElectricCommander \u2014 proprietary continuous integration and release management solution from Electric Cloud\n FinalBuilder Server \u2014 proprietary automated build and continuous integration server by VSoft Technologies\n Go \u2014 proprietary agile build and release management software by Thoughtworks\n Jenkins (formerly known as Hudson) \u2014 MIT-licensed, written in Java, runs in servlet container, supports CVS, Subversion, Mercurial, Git, StarTeam, Clearcase, Ant, NAnt, Maven, and shell scripts\n Software Configuration and Library Manager \u2014 software configuration management system for z\/OS by IBM Rational Software\n QuickBuild - proprietary continuous integration server with free community edition featuring build life cycle management and pre-commit verification.\n TeamCity \u2014 proprietary continuous-integration server by JetBrains with free professional edition\n Team Foundation Server \u2014 proprietary continuous integration server and source code repository by Microsoft\n Tinderbox \u2014 Mozilla-based product written in Perl\n Rational Team Concert \u2014 proprietary software development collaboration platform with built-in build engine by IBM including Rational Build Forge\nSee the links to in-depth feature matrix in the external links for deeper comparisons.\n\nFurther reading \n Duvall, P.M. (2007). Continuous Integration. Improving Software Quality and Reducing Risk. Addison-Wesley. ISBN 0321336380.   <\/ref>\nReferences \n\n\n\u2191 Cunningham, W. (20 December 2012). \"Integration Hell\". WikiWikiWeb. http:\/\/c2.com\/cgi\/wiki?IntegrationHell . Retrieved 27 April 2016 .   \n\n\u2191 Brauneis, D.; H\u00fcttermann, M. (16 January 2010). \"[OSLC Possible new Working Group - Automation\"]. open-services.net. http:\/\/open-services.net\/pipermail\/community_open-services.net\/2010-January\/000214.html . Retrieved 27 April 2016 .   \n\n\u2191 Taylor, B. (10 February 2009). \"Rails Deployment and Automation with ShadowPuppet and Capistrano\". Rails Machine. Archived from the original on 03 March 2011. https:\/\/web.archive.org\/web\/20110303225845\/http:\/\/blog.railsmachine.com\/articles\/2009\/02\/10\/rails-deployment-and-automation-with-shadowpuppet-and-capistrano . Retrieved 27 April 2016 .   \n\n\u2191 4.0 4.1 4.2 Fowler, M. (01 May 2006). \"Continuous Integration\". MartinFowler.com. http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html . Retrieved 27 April 2016 .   \n\n\u2191 Ries, E. (30 March 2009). \"Continuous deployment in 5 easy steps\". O'Reilly Radar. O'Reilly Media, Inc. http:\/\/radar.oreilly.com\/2009\/03\/continuous-deployment-5-eas.html . Retrieved 27 April 2016 .   \n\n\u2191 Fitz, T. (10 February 2009). \"Continuous Deployment at IMVU: Doing the impossible fifty times a day\". timothyfitz.com. http:\/\/timothyfitz.com\/2009\/02\/10\/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day\/ . Retrieved 27 April 2016 .   \n\n\u2191 Richardson, J. (14 September 2008). \"Agile Software Testing Strategies at No Fluff Just Stuff Conference\". Boston, Massachusetts. https:\/\/nofluffjuststuff.com\/conference\/boston\/2008\/09\/session?id=11645 . Retrieved 27 April 2016 .   \n\n\nExternal links \n Comparison of continuous integration software \n Continuous integration by Martin Fowler (an introduction)\n Continuous Integration at the Portland Pattern Repository (a collegial discussion)\n Cross platform testing at the Portland Pattern Repository\n Continuous Integration Server Feature Matrix (archived version of guide to tools)\n Continuous Integration: The Cornerstone of a Great Shop by Jared Richardson (an introduction)\n A Recipe for Build Maintainability and Reusability by Jay Flowers\n Continuous Integration anti-patterns by Paul Duvall\n Extreme programming \n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 21:05.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 897 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","a2777f409854379de217cacc4dde9d3a_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Continuous_Integration_Part_2 skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Continuous Integration: Part 2<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n<p><br \/>\n<b>Note<\/b>: The following content originates from <a href=\"https:\/\/en.wikibooks.org\/wiki\/Introduction_to_Software_Engineering\/Tools\/Continuous_Integration\" class=\"extiw\" title=\"wikibooks:Introduction to Software Engineering\/Tools\/Continuous Integration\" rel=\"external_link\" target=\"_blank\">a separate source<\/a>. However, it elaborates further on the original author's ideas in the <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\/Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"8aa7cf5a1a2f18bd7ab6b7269eff4787\">previous section<\/a> and adds additional information regarding benefits, drawbacks, and tools other than Jenkins, Trac, and Redmine. It has been added and slightly modified under the <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/creativecommons.org\/licenses\/by-sa\/3.0\/\" target=\"_blank\">same license<\/a> as the rest of the content.\n<\/p>\n\n\n<h2><span class=\"mw-headline\" id=\"Theory\">Theory<\/span><\/h2>\n<p>When embarking on a change, a developer takes a copy of the current code base on which to work. As other developers submit changed code to the code repository, this copy gradually ceases to reflect the repository code. When developers submit code to the repository, they must first update their code to reflect the changes in the repository since they took their copy. The more changes the repository contains, the more work developers must do before submitting their own changes.\n<\/p><p>Eventually, the repository may become so different from the developers' baselines that they enter what is sometimes called \"integration hell\",<sup id=\"rdp-ebb-cite_ref-CunninghamInt09_1-0\" class=\"reference\"><a href=\"#cite_note-CunninghamInt09-1\" rel=\"external_link\">[1]<\/a><\/sup> where the time it takes to integrate exceeds the time it took to make their original changes. In a worst-case scenario, developers may have to discard their changes and completely redo the work.\n<\/p><p>Continuous integration involves integrating early and often, so as to avoid the pitfalls of \"integration hell.\" The practice aims to reduce rework and thus reduce cost and time, particularly when automated as a best practice.<sup id=\"rdp-ebb-cite_ref-BrauneisOSLC_2-0\" class=\"reference\"><a href=\"#cite_note-BrauneisOSLC-2\" rel=\"external_link\">[2]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-TaylorRails09_3-0\" class=\"reference\"><a href=\"#cite_note-TaylorRails09-3\" rel=\"external_link\">[3]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Recommended_practices\">Recommended practices<\/span><\/h2>\n<p>Continuous integration should occur frequently enough that no intervening window remains between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately.<sup id=\"rdp-ebb-cite_ref-FowlerCI00_4-0\" class=\"reference\"><a href=\"#cite_note-FowlerCI00-4\" rel=\"external_link\">[4]<\/a><\/sup> Normal practice is to trigger these builds by every commit to a repository, rather than a periodically scheduled build. The practicalities of doing this in a multi-developer environment of rapid commits are such that it's usual to trigger a short timer after each commit, then to start a build when either this timer expires, or after a rather longer interval since the last build. Automated tools such as CruiseControl or Jenkins offer this scheduling automatically.\n<\/p><p>Another factor is the need for a version control system that supports atomic commits, i.e. all of a developer's changes may be seen as a single commit operation. There is no point in trying to build from only half of the changed files.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Maintain_a_code_repository\">Maintain a code repository<\/span><\/h3>\n<p>This practice advocates the use of a revision control system for the project's source code. All artifacts required to build the project should be placed in the repository. In this practice and in the revision control community, the convention is that the system should be buildable from a fresh checkout and not require additional dependencies. Extreme Programming advocate Martin Fowler also mentions that where branching is supported by tools, its use should be minimized.<sup id=\"rdp-ebb-cite_ref-FowlerCI00_4-1\" class=\"reference\"><a href=\"#cite_note-FowlerCI00-4\" rel=\"external_link\">[4]<\/a><\/sup> Instead, integrating changes is preferred rather than creating multiple versions of the software that are maintained simultaneously. The mainline (or trunk) should be the place for the working version of the software.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Automate_the_build\">Automate the build<\/span><\/h3>\n<p>A single command should have the capability of building the system. Many build-tools, such as make, have existed for years. Other more recent tools like Ant, Maven, MSBuild or IBM Rational Build Forge are frequently used in continuous integration environments. Automation of the build should include automating the integration, which often includes deployment into a production-like environment. In many cases, the build script not only compiles binaries, but also generates documentation, website pages, statistics, and distribution media (such as Windows MSI files, RPM or DEB files).\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Make_the_build_self-testing\">Make the build self-testing<\/span><\/h3>\n<p>Once the code is built, all tests should run to confirm that it behaves as the developers expect it to behave.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Everyone_commits_to_the_baseline_every_day\">Everyone commits to the baseline every day<\/span><\/h3>\n<p>By committing regularly, every committer can reduce the number of conflicting changes. Checking in a week's worth of work runs the risk of conflicting with other features and can be very difficult to resolve. Early, small conflicts in an area of the system cause team members to communicate about the change they are making.\n<\/p><p>Many programmers recommend committing all changes at least once a day (once per feature built), and in addition performing a nightly build.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Every_commit_.28to_baseline.29_should_be_built\">Every commit (to baseline) should be built<\/span><\/h3>\n<p>The system should build commits to the current working version in order to verify that they integrate correctly. A common practice is to use automated continuous integration, although this may be done manually. For many, continuous integration is synonymous with using automated continuous integration where a continuous integration server or daemon monitors the version control system for changes, then automatically runs the build process.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Keep_the_build_fast\">Keep the build fast<\/span><\/h3>\n<p>The build needs to complete rapidly, so that if there is a problem with integration, it is quickly identified.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Test_in_a_clone_of_the_production_environment\">Test in a clone of the production environment<\/span><\/h3>\n<p>Having a test environment can lead to failures in tested systems when they deploy in the production environment, because the production environment may differ from the test environment in a significant way. However, building a replica of a production environment is cost prohibitive. Instead, the pre-production environment should be built to be a scalable version of the actual production environment to both alleviate costs while maintaining technology stack composition and nuances.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Make_it_easy_to_get_the_latest_deliverables\">Make it easy to get the latest deliverables<\/span><\/h3>\n<p>Making builds readily available to stakeholders and testers can reduce the amount of rework necessary when rebuilding a feature that doesn't meet requirements. Additionally, early testing reduces the chances that defects survive until deployment. Finding errors earlier also, in some cases, reduces the amount of work necessary to resolve them.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Everyone_can_see_the_results_of_the_latest_build\">Everyone can see the results of the latest build<\/span><\/h3>\n<p>It should be easy to find out where\/whether the build breaks and who made the relevant change.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Automate_deployment\">Automate deployment<\/span><\/h3>\n<p>Most CI systems allow the running of scripts after a build finishes. In most situations, it is possible to write a script to deploy the application to a live test server that everyone can look at. A further advance in this way of thinking is the concept of \"continuous deployment,\" which calls for the software to be deployed directly into production, often with additional automation to prevent defects or regressions.<sup id=\"rdp-ebb-cite_ref-RiesCont09_5-0\" class=\"reference\"><a href=\"#cite_note-RiesCont09-5\" rel=\"external_link\">[5]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FitzCont09_6-0\" class=\"reference\"><a href=\"#cite_note-FitzCont09-6\" rel=\"external_link\">[6]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Advantages_and_disadvantages\">Advantages and disadvantages<\/span><\/h2>\n<h3><span class=\"mw-headline\" id=\"Advantages\">Advantages<\/span><\/h3>\n<p>Continuous integration has many advantages<sup id=\"rdp-ebb-cite_ref-FowlerCI00_4-2\" class=\"reference\"><a href=\"#cite_note-FowlerCI00-4\" rel=\"external_link\">[4]<\/a><\/sup>:\n<\/p>\n<ul><li> ability to revert the codebase back to a bug-free state, without wasting time debugging, when unit tests fail or a bug emerges;<\/li>\n<li> ability to detect and fix integration problems continuously, avoiding last-minute chaos at release dates (when everyone tries to check in their slightly incompatible versions);<\/li>\n<li> early warning of broken\/incompatible code;<\/li>\n<li> early warning of conflicting changes;<\/li>\n<li> immediate unit testing of all changes;<\/li>\n<li> constant availability of a \"current\" build for testing, demo, or release purposes;<\/li>\n<li> immediate feedback to developers on the quality, functionality, or system-wide impact of code they are writing;<\/li>\n<li> modular, less complex code often a result of frequent code check-in by developers; and<\/li>\n<li> metrics generated from automated testing and CI (such as metrics for code coverage, code complexity, and features complete) focus developers on developing functional, quality code, and help develop momentum in a team.<\/li><\/ul>\n<h3><span class=\"mw-headline\" id=\"Disadvantages\">Disadvantages<\/span><\/h3>\n<ul><li> initial setup time required;<\/li>\n<li> well-developed test-suite required to achieve automated testing advantages;<\/li>\n<li> large-scale refactoring can be troublesome due to continuously changing code base; and<\/li>\n<li> hardware costs for build machines can be significant.<\/li><\/ul>\n<p>Many teams using CI report that the advantages of CI well outweigh the disadvantages.<sup id=\"rdp-ebb-cite_ref-RichardsonAgile08_7-0\" class=\"reference\"><a href=\"#cite_note-RichardsonAgile08-7\" rel=\"external_link\">[7]<\/a><\/sup> The effect of finding and fixing integration bugs early in the development process saves both time and money over the lifespan of a project.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Software\">Software<\/span><\/h2>\n<p>To support continuous integration, software tools such as automated build software can be employed.\n<\/p><p>Software tools for continuous integration include:\n<\/p>\n<ul><li> AnthillPro \u2014 continuous integration server by Urbancode<\/li>\n<li> Apache Continuum \u2014 continuous integration server supporting Apache Maven and Apache Ant. Supports CVS, Subversion, Ant, Maven, and shell scripts<\/li>\n<li> Apache Gump \u2014 continuous integration tool by Apache<\/li>\n<li> Automated Build Studio \u2014 proprietary automated build, continuous integration and release management system by AutomatedQA<\/li>\n<li> Bamboo \u2014 proprietary continuous integration server by Atlassian Software Systems<\/li>\n<li> BuildBot \u2014 Python\/Twisted-based continuous build system<\/li>\n<li> BuildForge - proprietary automated build engine by IBM \/ Rational<\/li>\n<li> BuildMaster \u2014 proprietary application lifecycle management and continuous integration tool by Inedo<\/li>\n<li> CABIE - Continuous Automated Build and Integration Environment \u2014 open source, written in Perl; works with CVS, Subversion, AccuRev, Bazaar and Perforce<\/li>\n<li> Cascade \u2014 proprietary continuous integration tool; provides a checkpointing facility to build and test changes before they are committed<\/li>\n<li> codeBeamer \u2014 proprietary collaboration software with built-in continuous integration features<\/li>\n<li> CruiseControl \u2014 Java-based framework for a continuous build process<\/li>\n<li> CruiseControl.NET \u2014 .NET-based automated continuous integration server<\/li>\n<li> CruiseControl.rb - Lightweight, Ruby-based continuous integration server that can build any codebase, not only Ruby, released under Apache Licence 2.0<\/li>\n<li> ElectricCommander \u2014 proprietary continuous integration and release management solution from Electric Cloud<\/li>\n<li> FinalBuilder Server \u2014 proprietary automated build and continuous integration server by VSoft Technologies<\/li>\n<li> Go \u2014 proprietary agile build and release management software by Thoughtworks<\/li>\n<li> Jenkins (formerly known as Hudson) \u2014 MIT-licensed, written in Java, runs in servlet container, supports CVS, Subversion, Mercurial, Git, StarTeam, Clearcase, Ant, NAnt, Maven, and shell scripts<\/li>\n<li> Software Configuration and Library Manager \u2014 software configuration management system for z\/OS by IBM Rational Software<\/li>\n<li> QuickBuild - proprietary continuous integration server with free community edition featuring build life cycle management and pre-commit verification.<\/li>\n<li> TeamCity \u2014 proprietary continuous-integration server by JetBrains with free professional edition<\/li>\n<li> Team Foundation Server \u2014 proprietary continuous integration server and source code repository by Microsoft<\/li>\n<li> Tinderbox \u2014 Mozilla-based product written in Perl<\/li>\n<li> Rational Team Concert \u2014 proprietary software development collaboration platform with built-in build engine by IBM including Rational Build Forge<\/li><\/ul>\n<p>See the links to in-depth feature matrix in the external links for deeper comparisons.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Further_reading\">Further reading<\/span><\/h2>\n<ul><li> <span class=\"citation book\">Duvall, P.M. (2007). <i>Continuous Integration. Improving Software Quality and Reducing Risk<\/i>. Addison-Wesley. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 0321336380.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Continuous+Integration.+Improving+Software+Quality+and+Reducing+Risk&rft.aulast=Duvall%2C+P.M.&rft.au=Duvall%2C+P.M.&rft.date=2007&rft.pub=Addison-Wesley&rft.isbn=0321336380&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/ref><\/li><\/ul>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-CunninghamInt09-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-CunninghamInt09_1-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Cunningham, W. (20 December 2012). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/c2.com\/cgi\/wiki?IntegrationHell\" target=\"_blank\">\"Integration Hell\"<\/a>. <i>WikiWikiWeb<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/c2.com\/cgi\/wiki?IntegrationHell\" target=\"_blank\">http:\/\/c2.com\/cgi\/wiki?IntegrationHell<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Integration+Hell&rft.atitle=WikiWikiWeb&rft.aulast=Cunningham%2C+W.&rft.au=Cunningham%2C+W.&rft.date=20+December+2012&rft_id=http%3A%2F%2Fc2.com%2Fcgi%2Fwiki%3FIntegrationHell&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-BrauneisOSLC-2\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-BrauneisOSLC_2-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Brauneis, D.; H\u00fcttermann, M. (16 January 2010). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/open-services.net\/pipermail\/community_open-services.net\/2010-January\/000214.html\" target=\"_blank\">\"[OSLC<\/a> Possible new Working Group - Automation\"]. <i>open-services.net<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/open-services.net\/pipermail\/community_open-services.net\/2010-January\/000214.html\" target=\"_blank\">http:\/\/open-services.net\/pipermail\/community_open-services.net\/2010-January\/000214.html<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=%5BOSLC%5D+Possible+new+Working+Group+-+Automation&rft.atitle=open-services.net&rft.aulast=Brauneis%2C+D.%3B+H%C3%BCttermann%2C+M.&rft.au=Brauneis%2C+D.%3B+H%C3%BCttermann%2C+M.&rft.date=16+January+2010&rft_id=http%3A%2F%2Fopen-services.net%2Fpipermail%2Fcommunity_open-services.net%2F2010-January%2F000214.html&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-TaylorRails09-3\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-TaylorRails09_3-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Taylor, B. (10 February 2009). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/web.archive.org\/web\/20110303225845\/http:\/\/blog.railsmachine.com\/articles\/2009\/02\/10\/rails-deployment-and-automation-with-shadowpuppet-and-capistrano\" target=\"_blank\">\"Rails Deployment and Automation with ShadowPuppet and Capistrano\"<\/a>. <i>Rails Machine<\/i>. Archived from <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/blog.railsmachine.com\/articles\/2009\/02\/10\/rails-deployment-and-automation-with-shadowpuppet-and-capistrano\/\" target=\"_blank\">the original<\/a> on 03 March 2011<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/web.archive.org\/web\/20110303225845\/http:\/\/blog.railsmachine.com\/articles\/2009\/02\/10\/rails-deployment-and-automation-with-shadowpuppet-and-capistrano\" target=\"_blank\">https:\/\/web.archive.org\/web\/20110303225845\/http:\/\/blog.railsmachine.com\/articles\/2009\/02\/10\/rails-deployment-and-automation-with-shadowpuppet-and-capistrano<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Rails+Deployment+and+Automation+with+ShadowPuppet+and+Capistrano&rft.atitle=Rails+Machine&rft.aulast=Taylor%2C+B.&rft.au=Taylor%2C+B.&rft.date=10+February+2009&rft_id=https%3A%2F%2Fweb.archive.org%2Fweb%2F20110303225845%2Fhttp%3A%2F%2Fblog.railsmachine.com%2Farticles%2F2009%2F02%2F10%2Frails-deployment-and-automation-with-shadowpuppet-and-capistrano&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FowlerCI00-4\"><span class=\"mw-cite-backlink\">\u2191 <sup><a href=\"#cite_ref-FowlerCI00_4-0\" rel=\"external_link\">4.0<\/a><\/sup> <sup><a href=\"#cite_ref-FowlerCI00_4-1\" rel=\"external_link\">4.1<\/a><\/sup> <sup><a href=\"#cite_ref-FowlerCI00_4-2\" rel=\"external_link\">4.2<\/a><\/sup><\/span> <span class=\"reference-text\"><span class=\"citation web\">Fowler, M. (01 May 2006). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html\" target=\"_blank\">\"Continuous Integration\"<\/a>. <i>MartinFowler.com<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html\" target=\"_blank\">http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Continuous+Integration&rft.atitle=MartinFowler.com&rft.aulast=Fowler%2C+M.&rft.au=Fowler%2C+M.&rft.date=01+May+2006&rft_id=http%3A%2F%2Fwww.martinfowler.com%2Farticles%2FcontinuousIntegration.html&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-RiesCont09-5\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-RiesCont09_5-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Ries, E. (30 March 2009). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/radar.oreilly.com\/2009\/03\/continuous-deployment-5-eas.html\" target=\"_blank\">\"Continuous deployment in 5 easy steps\"<\/a>. <i>O'Reilly Radar<\/i>. O'Reilly Media, Inc<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/radar.oreilly.com\/2009\/03\/continuous-deployment-5-eas.html\" target=\"_blank\">http:\/\/radar.oreilly.com\/2009\/03\/continuous-deployment-5-eas.html<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Continuous+deployment+in+5+easy+steps&rft.atitle=O%27Reilly+Radar&rft.aulast=Ries%2C+E.&rft.au=Ries%2C+E.&rft.date=30+March+2009&rft.pub=O%27Reilly+Media%2C+Inc&rft_id=http%3A%2F%2Fradar.oreilly.com%2F2009%2F03%2Fcontinuous-deployment-5-eas.html&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FitzCont09-6\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FitzCont09_6-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Fitz, T. (10 February 2009). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/timothyfitz.com\/2009\/02\/10\/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day\/\" target=\"_blank\">\"Continuous Deployment at IMVU: Doing the impossible fifty times a day\"<\/a>. <i>timothyfitz.com<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/timothyfitz.com\/2009\/02\/10\/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day\/\" target=\"_blank\">http:\/\/timothyfitz.com\/2009\/02\/10\/continuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day\/<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Continuous+Deployment+at+IMVU%3A+Doing+the+impossible+fifty+times+a+day&rft.atitle=timothyfitz.com&rft.aulast=Fitz%2C+T.&rft.au=Fitz%2C+T.&rft.date=10+February+2009&rft_id=http%3A%2F%2Ftimothyfitz.com%2F2009%2F02%2F10%2Fcontinuous-deployment-at-imvu-doing-the-impossible-fifty-times-a-day%2F&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-RichardsonAgile08-7\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-RichardsonAgile08_7-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation book\">Richardson, J. (14 September 2008). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/nofluffjuststuff.com\/conference\/boston\/2008\/09\/session?id=11645\" target=\"_blank\">\"<i>Agile Software Testing Strategies<\/i> at No Fluff Just Stuff Conference\"<\/a>. Boston, Massachusetts<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/nofluffjuststuff.com\/conference\/boston\/2008\/09\/session?id=11645\" target=\"_blank\">https:\/\/nofluffjuststuff.com\/conference\/boston\/2008\/09\/session?id=11645<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=%27%27Agile+Software+Testing+Strategies%27%27+at+No+Fluff+Just+Stuff+Conference&rft.atitle=&rft.aulast=Richardson%2C+J.&rft.au=Richardson%2C+J.&rft.date=14+September+2008&rft.place=Boston%2C+Massachusetts&rft_id=https%3A%2F%2Fnofluffjuststuff.com%2Fconference%2Fboston%2F2008%2F09%2Fsession%3Fid%3D11645&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<\/ol><\/div>\n<h2><span class=\"mw-headline\" id=\"External_links\">External links<\/span><\/h2>\n<ul><li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/Comparison_of_continuous_integration_software\" target=\"_blank\">Comparison of continuous integration software<\/a> <\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html\" target=\"_blank\">Continuous integration<\/a> by Martin Fowler (an introduction)<\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.c2.com\/cgi\/wiki?ContinuousIntegration\" target=\"_blank\">Continuous Integration at the Portland Pattern Repository<\/a> (a collegial discussion)<\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/c2.com\/cgi\/wiki?CrossPlatformTesting\" target=\"_blank\">Cross platform testing at the Portland Pattern Repository<\/a><\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/web.archive.org\/web\/20150504203619\/http:\/\/confluence.public.thoughtworks.org\/display\/CC\/CI+Feature+Matrix\" target=\"_blank\">Continuous Integration Server Feature Matrix<\/a> (archived version of guide to tools)<\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.methodsandtools.com\/archive\/archive.php?id=42\" target=\"_blank\">Continuous Integration: The Cornerstone of a Great Shop<\/a> by Jared Richardson (an introduction)<\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/jayflowers.com\/joomla\/index.php?option=com_content&task=view&id=26\" target=\"_blank\">A Recipe for Build Maintainability and Reusability<\/a> by Jay Flowers<\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.ibm.com\/developerworks\/java\/library\/j-ap11297\/\" target=\"_blank\">Continuous Integration anti-patterns<\/a> by Paul Duvall<\/li>\n<li> <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.extremeprogramming.org\/rules\/integrateoften.html\" target=\"_blank\">Extreme programming <\/a><\/li><\/ul>\n\n<!-- \nNewPP limit report\nCached time: 20190104224853\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.205 seconds\nReal time usage: 0.227 seconds\nPreprocessor visited node count: 5186\/1000000\nPreprocessor generated node count: 19658\/1000000\nPost\u2010expand include size: 35965\/2097152 bytes\nTemplate argument size: 15188\/2097152 bytes\nHighest expansion depth: 12\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 191.829 1 - -total\n 80.82% 155.035 8 - Template:Citation\/core\n 74.82% 143.529 1 - Template:Reflist\n 54.33% 104.227 6 - Template:Cite_web\n 25.10% 48.142 1 - Template:Cite_book\n 11.84% 22.717 1 - Template:Cite_conference\n 6.02% 11.558 15 - Template:Citation\/make_link\n 4.59% 8.805 1 - Template:Citation\/identifier\n 1.09% 2.093 1 - Template:Only_in_print\n 1.07% 2.052 2 - Template:Hide_in_print\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8684-0!*!0!!en!*!* and timestamp 20190104224853 and revision id 25242\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","a2777f409854379de217cacc4dde9d3a_images":[],"a2777f409854379de217cacc4dde9d3a_timestamp":1546642133,"8aa7cf5a1a2f18bd7ab6b7269eff4787_type":"article","8aa7cf5a1a2f18bd7ab6b7269eff4787_title":"Why continuous integration?","8aa7cf5a1a2f18bd7ab6b7269eff4787_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration","8aa7cf5a1a2f18bd7ab6b7269eff4787_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Continuous Integration\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\nContents\n\n1 Should I use continuous integration builds? \n2 Why is continuous integration a necessity? \n3 Jenkins CI \n4 What's so great about a CI build? \n\n4.1 Tracing of builds to a changeset \n4.2 Immediate feedback \n4.3 Central build location \n4.4 Unit tests are run over and over (and over) \n4.5 Integration with other nice-to-haves, such as Findbugs, PMD, and Cobertura \n\n\n5 Releasing software \n6 Ticketing and issue tracing \n\n6.1 Redmine \n6.2 The issue tracking system \n\n\n7 References \n\n\n\nShould I use continuous integration builds? \nYes, a software project should have continuous integration (CI) builds. This goes for projects with a large team as well as projects with a small team. While the CI build is very useful for a large group to collaborate, there is tremendous value even for the smallest team. Even a software engineer working alone can benefit from a continuous integration build.\n\nWhy is continuous integration a necessity? \n The CI Environment provides all that is needed for the DHF.\nFirst, a reminder of the definition we're using:\n\nIn software engineering, continuous integration (CI) implements continuous processes of applying quality control \u2014 small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.[1]\nA continuous integration (CI) tool is no longer simply something that is \"nice to have\" during project development. As someone who has spent more time than I care to discuss wading through documents and making sure references, traceability, document versions, and design outputs are properly documented in a design history file (DHF), I hope to make the value of using CI to automate such tedious and error prone manual labor clear. CI shouldn\u2019t be though of as \"nice to have.\" On the contrary, it is an absolute necessity!\nWhen I say that continuous integration is an absolute necessity, I mean that both the CI tool and the process are needed. A CI tool takes the attempts \u2014 sometimes feeble \u2014 of humans to make large amounts of documentation consistently traceable and forces the computer system to do what it does best. The use of a CI tool is not simply an esoteric practice for those who are fond of its incorporation. As you will learn in this chapter, utilizing software tools to ease the continuous integration process is something that good development teams have always attempted but have too often failed to do. Going a step further, development teams can use CI tools to simplify steps that they may never have dreamed of before!\nContinuous integration refers to both the continuous compiling and building of a project tree and the continuous testing, releasing, and quality control of the project as a while. This means that throughout the project, at every stage, the development team will have a build available with at least partial documentation and testing included. The CI build is used to perform certain tasks at certain times. In general, this simply means that builds are performed in an environment that closely matches the actual production environment of the system. In addition, a CI environment should be used to provide statistical feedback on build performance, tests, and incorporation of a version control system and ticketing system. In a development environment, the team may use a version control tool (i. e. Subversion) to link to tickets. As such, any CI build will be linked to a specific changeset, thereby providing linkage to issues, requirements, and, ultimately, the trace matrix. To this end, the CI environment, used properly, can be the DHF.\nA development team should attempt to perform continuous integration builds frequently enough that no window of additional version control update occurs between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately. This means that for a project that is in-development, it should be configured that a check triggers a build in a timely manner. Likewise, it is generally a good practice for the developer committing a changeset of code to verify that his or her own changeset does not break the continuous integration build.\nAllow me to address the word \"build.\" Most software engineers think of a build as the output of compiling and linking. I suggest moving away from this narrow definition and expanding it. A \"build\" is a completion (in both the compiler sense and beyond) of all things necessary for a successful product delivery. A CI tool runs whatever scripts the development team tells it to run. As such, the team has the freedom to use the CI tool as a build manager (sorry build managers, I don\u2019t mean to threaten your job). It can compile code, create an installer, bundle any and all documents, create release notes, run tests, and alert team members about its progress.\n\nJenkins CI \nWhile there are many tools, I will focus on one of the most popular, Jenkins CI. The open-source tool Jenkins CI (the continuation of a product formerly called Hudson) allows continuous integration builds in the following ways:\n\n It integrates with popular build tools (ant, maven, make) so that it can run the appropriate build scripts to compile, test, and package within an environment that closely matches what will be the production environment.\n It integrates with version control tools, including Subversion, so that different projects can be set up depending on projection location within the trunk.\n It can be configured to trigger builds automatically by time and\/or changeset (i.e. if a new changeset is detected in the Subversion repository for the project, a new build is triggered).\n It reports on build status. If the build is broken, it can be configured to alert individuals by email.\nThe above screenshot gives an example of what a main page for Jenkins CI (or any CI tool) may look like. It can be configured to allow logins at various levels and on a per-project basis. This main page lists all the projects that are currently active, along with a status (a few details about the build) and some configuration links on the side. These links may not be available to a general user.\nClicking any project (\"job\") links to further details on the build history and status. This image provides us details on what the overview screen in the CI environment might look like, but it is at the detailed project level that we see the real benefit of packaging that can be performed by a well setup CI environment.\n\nWhat's so great about a CI build? \nTracing of builds to a changeset \nOkay, so I\u2019m starting to sound repetitive, but tracing is a good thing, and with this setup I can trace all over the place! With the entire process in place \u2014 from standard operating procedures to work instructions and from use cases and requirements to tickets and changests \u2014 how do we know that the team members working on a project are actually following procedure? The CI environment, at least with regard to the ongoing development of code, gives us a single point of view for all other activities. From here we can see changesets, tickets, build status, and test coverage. Using the proper add-ons, we can even gain insight into the quality of the code that is being developed.\nTo pull this off, of course, we need to use our ticketing system wisely. With Redmine, or just about any other good ticketing system, we can capture elements of software requirements and software design as parent tickets. These parent tickets have one to many sub-tickets, which themselves can have sub-tickets. A parent ticket may not be closed or marked complete until a child ticket is completed.\n\nImmediate feedback \nAt its most basic level, Jenkins CI only does one thing: it runs whatever scripts we tell it to. The power of Jenkins CI is that we can tell it to run whatever we want, log the outcome, keep build artifacts, run third-party evaluation tools, and report on results. With Subversion integration, Jenkins CI will display the changeset relevant to a particular build. It can be configured to generate a build at whatever interval we want (nightly, hourly, every time there is a code commit, etc.).\nPersonally, every time I do any code commit of significance, one of the first things I do is check the CI build for success. If I\u2019ve broken the build, I get to work on correcting the problem (and if I cannot correct the problem quickly, I roll my changeset out so that the CI build continues to work until I\u2019ve fixed the issue).\nJenkins can be configured to email team members on build results, and it may be useful to set it up so that developers are emailed should a build break.\n\nCentral build location \nThe build artifacts of your project, in general, should not be a part of the repository (there are exceptions to this rule). Build artifacts belong in your continuous integration build tool, where they can be viewed and used by anyone on the team who needs them. These artifacts include test results, compiled libraries, and executables. Too often a released build is created locally on some developer\u2019s machine. This is a serious problem since we have no good way of knowing what files were actually used to create that build. Was there a configuration change? A bug introduced? An incorrect file version?\nWhile developers have good reason to generate and test build locally, a formal build used for testing (or, more importantly, release) must never be created locally. Never.\nBuild artifacts are not checked in to the source control repository for a number of reasons, but the biggest reason is because we never want to make assumptions about the environment in which those items were built. The build artifacts should instead remain in our CI environment, where we know the conditions within which the build was generated.\nAlso, because these builds remain easily accessible and labeled in the CI build environment, any team member can easily access any given build. In particular, it may become necessary to use a specific build to recreate an issue in a build that has been released for internal or external use. Because we know the label of the build (the version number given to it) as well as the repository changeset number of the build (because our build and install scripts include it), we know precisely which build to pull from the CI build server to recreate the necessary conditions.\n\nUnit tests are run over and over (and over) \nDevelopers should do whatever they can to keep the CI build from breaking. Of course, this doesn\u2019t always work well. I\u2019ve broken the CI build countless times for a number of reasons:\n\n I forgot to add a necessary library or new file.\n I forgot to commit a configuration change.\n I accidentally included a change in my changeset.\n It worked locally but not when built on the CI build server (this is why the CI build server should, as much as possible, mimic the production environment).\n Unit tests worked locally but not on the CI build server because of some environmental difference.\nIf not for a CI build environment with good unit tests, such problems would only be discovered at a later time or by some other frustrated team member. In this regard, the CI build saves us from many headaches.\nThe most difficult software defects to fix (much less, find) are the ones that do not happen consistently. Database locking issues, memory issues, and race conditions can result in such defects. These defects are serious, but if we never detect them, how can we fix them?\nIt\u2019s a good idea to have unit tests that go above and beyond what we traditionally think of as unit tests and perhaps go several steps further, such as automating functional testing. This is another one of those areas where team members often (incorrectly) feel that there is not sufficient time to do all the work.\nWith Jenkins running all of these tests every time a build is performed, we sometimes encounter situations where a test fails suddenly for no apparent reason. It worked before, an hour ago, and there has not been any change to the code, so what caused it to fail this time? Pay attention, because this WILL happen.\n\nIntegration with other nice-to-haves, such as Findbugs, PMD, and Cobertura \nWithout going into too much detail, there are great tools out there that can be used with Jenkins to evaluate the code for potential bugs, bad coding practices, and testing coverage. These tools definitely come in handy. Use them.\n\nReleasing software \nWhen software is released, it is typically given some kind of version number (e.g., 1.0). This is good, but it doesn\u2019t tell us the specifics of what went into that build. It\u2019s a good idea to include the Subversion changeset number somewhere in the release so that we always know EXACTLY what went into the build. I would include a build.xml (or build.prop) file somewhere that includes the version number of the release, the Subversion changeset number and the date of the build. As far as the last two values, these can (and should) be generated automatically by your build scripts.\nAs far as actually using Subversion within Linux\/Unix, all commands are available from the command line. When working in Windows, I really like using TortoiseSVN. It integrates with Windows File Explorer, showing icons that indicate the status of any versioned file. It also provides a nice interface for viewing file differences (even differences of your Word documents) and repository history.\n\nTicketing and issue tracing \nFor too long we\u2019ve thought of our ticketing systems as \"bug trackers.\" One of the previously most popular open-source tools, Bugzilla, even used the word \"bug\" in its name. But issue tracking does not need to imply that it is only useful for tracking software defects. On the contrary, it can be used for everything in software design and development, from addressing documentation needs to capturing software requirements and handling software defect reporting.\nOn that note, I would like to add something that may require an entire post. I think it might be best to get away from using standard documents for the capture of software use cases, requirements, hazards, and so on. By capturing everything related to a software project in our issue tracking tool, we can leverage the power of a tool like Trac or Redmine to enhance team collaboration and project tracing. But I won\u2019t bite off more than I can chew right now.\nWhen I first began writing all of these thoughts of mine down, I was going to use Trac as my example (http:\/\/trac.edgewall.org\/). Trac is a great tool, but there\u2019s something better now, and that something is Redmine (http:\/\/www.redmine.org\/).\nThe principal shortcoming of Trac is the fact that it doesn\u2019t lend itself well (at all) to handling multiple projects. One installation of Trac can be integrated with only a single Subversion repository, and the ticketing system can only handle a single project. I still like the way Trac can be used to group tickets into sprints, but by using sub-projects in Redmine, a similar grouping can be achieved. In the past, if a tool was used at all, we used Bugzilla or Clearquest to handle our issue tracking. These tools were very good at the time, but they did not integrate well with other tools, nor did they include features like wikis, calendars, or Gantt charts. (Admittedly, I have not used Clearquest in many years, so I really have no idea whether or not it has since addressed some of these needs.)\n\nRedmine \nSo what\u2019s so great about Redmine?\n\nWith the power of the wiki, your documents maintain all of your project management details, work instructions, use cases, requirements, and so on. Again, I think this information can be placed into the wiki, but that may be a step that not everyone is comfortable taking.\nThat said, all developer setup, lessons learned, and other informal notes can be placed in the wiki. One time I spent nearly four days tracking down a very strange defect. By the time I finally figured it all out I had learned a lot about a very strange issue that others were surely to encounter. I created a wiki page explaining the issue.\nAnother power feature of the wiki is the fact that with Redmine (and Trac) we can link not only to other wiki pages but also to tickets (issues), projects, sub-projects, and Subversion changesets. Again, more tracing. Nice.\nWith Subversion and Redmine integrated I can link back and forth between the two. Those work instructions explaining to the team how we will make use of our procedures should explain that no ticket can be closed without a link to a Subversion changeset (unless, of course, the ticket is rejected). Redmine can be configured to search for keywords in your Subversion changeset commit. For example, if I am checking in several files that address issue #501, I might put a comment like this: \"Corrected such and such. This fixes #501.\" We can configure Redmine to look for that word \"fixes\" and use it. Redmine may use that word as a flag to close the ticket and link to the changeset that was created when I did that commit. Likewise, when we view your Subversion history, we will see \"#501\" attached to the changeset as a link to the ticket. The tracing works both ways\u2026 Beautiful!\nIt has multiple project handling and integration with different Subversion repositories. This is a major reason why I (and others) switched to Redmine. Trac was great, but it only handled a single project. Redmine, with its handling of multiple projects, can be used corporate-wide for all development, and each project can be tied to a different Subversion repository. Additionally, a single project can have multiple sub-projects. This gives us the flexibility to use sub-projects for sprints, specific branched versions, and so on.\nWith Jenkins integrated, I don\u2019t have to leave the wiki to see how my CI builds look. Not only that, I can link to a specific CI build from any page within the wiki or ticketing system.\nEverything can be configured in Redmine. Yes, EVERYTHING. We can even configure the flow of tickets.\nThe issue tracking system \nI propose that it is not enough to simply leave functional requirements in the software requirements specification document. This does not provide sufficient tracing, nor does it provide a clear path from idea to functional code. Here are the steps that I suggest:\n\nAll requirements and software design items are entered as tickets. For now they are simply high-level tickets with no child tickets.\nThe development team, organized by a lead developer, breaks down each high-level ticket into as many child tickets as necessary. Using the ticketing system, we set up relationships so that the parent ticket (the requirement itself) cannot be closed until all child tickets are completed. (Note: It may be a good idea to require corresponding unit tests with each ticket.)\nHazards (and I'm not doing to bother an explanation of hazard and risk analysis in this article) are mitigated by a combination of documentation, requirements, and tests. We can leverage our ticketing system to capture our hazards and provide tracing in much the same way as with requirements. This does not remove the need for a traceability matrix, but it does enhance our ability to create and maintain it. (As a side note, I think it would be great to use the Redmine wiki for use cases, requirements, hazard analysis, software design documents, and traceability matrices, thereby allowing for linking within, but this may be a hard sell for now).\nNot all requirements are functional code requirements. Many are documentation and\/or quality requirements. These should be captured in the same ticketing system. Use the ability of the system to label the type of ticket to handle the fact that there are different categories. By doing this, even documentation requirements are traceable in our system.\nI'm not suggesting that the tickets will be locked down this early, not for a moment! Tickets are created, closed, and modified throughout project design and the development process. Our project plan (created before we started writing code) explains to us which tickets need to be done when, focusing more on the highest level tickets. That said, I find it best to use some sort of iterative approach (and allow the development team to use sub-iterations, or \"sprints\").\nReferences \n\n\n\u2191 \"Continuous integration\". Wikipedia. Wikimedia Foundation, Inc. 28 August 2011. https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578 . Retrieved 27 April 2016 .   \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 19:44.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 670 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","8aa7cf5a1a2f18bd7ab6b7269eff4787_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Continuous_Integration skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Continuous Integration<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n\n\n<h2><span class=\"mw-headline\" id=\"Should_I_use_continuous_integration_builds.3F\">Should I use continuous integration builds?<\/span><\/h2>\n<p>Yes, a software project should have continuous integration (CI) builds. This goes for projects with a large team as well as projects with a small team. While the CI build is very useful for a large group to collaborate, there is tremendous value even for the smallest team. Even a software engineer working alone can benefit from a continuous integration build.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Why_is_continuous_integration_a_necessity.3F\">Why is continuous integration a necessity?<\/span><\/h2>\n<div class=\"thumb tright\"><div class=\"thumbinner\" style=\"width:742px;\"><a href=\"https:\/\/www.limswiki.org\/index.php\/File:Continuous-integration-dhf.jpg\" class=\"image wiki-link\" target=\"_blank\" data-key=\"fbace622f0b4352ee98e831564424dee\"><img alt=\"\" src=\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/33\/Continuous-integration-dhf.jpg\" class=\"thumbimage\" style=\"width: 100%;max-width: 400px;height: auto;\" \/><\/a> <div class=\"thumbcaption\"><div class=\"magnify\"><a href=\"https:\/\/www.limswiki.org\/index.php\/File:Continuous-integration-dhf.jpg\" class=\"internal wiki-link\" title=\"Enlarge\" target=\"_blank\" data-key=\"fbace622f0b4352ee98e831564424dee\"><\/a><\/div>The CI Environment provides all that is needed for the DHF.<\/div><\/div><\/div>\n<p>First, a reminder of the definition we're using:\n<\/p>\n<blockquote>In software engineering, continuous integration (CI) implements continuous processes of applying quality control \u2014 small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.<sup id=\"rdp-ebb-cite_ref-WPContIntAug11_1-0\" class=\"reference\"><a href=\"#cite_note-WPContIntAug11-1\" rel=\"external_link\">[1]<\/a><\/sup><\/blockquote>\n<p>A continuous integration (CI) tool is no longer simply something that is \"nice to have\" during project development. As someone who has spent more time than I care to discuss wading through documents and making sure references, traceability, document versions, and design outputs are properly documented in a design history file (DHF), I hope to make the value of using CI to automate such tedious and error prone manual labor clear. CI shouldn\u2019t be though of as \"nice to have.\" On the contrary, <b>it is an absolute necessity<\/b>!\n<\/p><p>When I say that continuous integration is an absolute necessity, I mean that both the CI tool and the process are needed. A CI tool takes the attempts \u2014 sometimes feeble \u2014 of humans to make large amounts of documentation consistently traceable and forces the computer system to do what it does best. The use of a CI tool is not simply an esoteric practice for those who are fond of its incorporation. As you will learn in this chapter, utilizing software tools to ease the continuous integration process is something that good development teams have always attempted but have too often failed to do. Going a step further, development teams can use CI tools to simplify steps that they may never have dreamed of before!\n<\/p><p>Continuous integration refers to both the continuous compiling and building of a project tree and the continuous testing, releasing, and quality control of the project as a while. This means that throughout the project, at every stage, the development team will have a build available with at least partial documentation and testing included. The CI build is used to perform certain tasks at certain times. In general, this simply means that builds are performed in an environment that closely matches the actual production environment of the system. In addition, a CI environment should be used to provide statistical feedback on build performance, tests, and incorporation of a version control system and ticketing system. In a development environment, the team may use a version control tool (i. e. Subversion) to link to tickets. As such, any CI build will be linked to a specific changeset, thereby providing linkage to issues, requirements, and, ultimately, the trace matrix. To this end, the CI environment, used properly, can be the DHF.\n<\/p><p>A development team should attempt to perform continuous integration builds frequently enough that no window of additional version control update occurs between commit and build, and such that no errors can arise without developers noticing them and correcting them immediately. This means that for a project that is in-development, it should be configured that a check triggers a build in a timely manner. Likewise, it is generally a good practice for the developer committing a changeset of code to verify that his or her own changeset does not break the continuous integration build.\n<\/p><p>Allow me to address the word \"build.\" Most software engineers think of a build as the output of compiling and linking. I suggest moving away from this narrow definition and expanding it. A \"build\" is a completion (in both the compiler sense and beyond) of all things necessary for a successful product delivery. A CI tool runs whatever scripts the development team tells it to run. As such, the team has the freedom to use the CI tool as a build manager (sorry build managers, I don\u2019t mean to threaten your job). It can compile code, create an installer, bundle any and all documents, create release notes, run tests, and alert team members about its progress.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Jenkins_CI\">Jenkins CI<\/span><\/h2>\n<p>While there are many tools, I will focus on one of the most popular, Jenkins CI. The open-source tool Jenkins CI (the continuation of a product formerly called Hudson) allows continuous integration builds in the following ways:\n<\/p>\n<ol><li> It integrates with popular build tools (ant, maven, make) so that it can run the appropriate build scripts to compile, test, and package within an environment that closely matches what will be the production environment.<\/li>\n<li> It integrates with version control tools, including Subversion, so that different projects can be set up depending on projection location within the trunk.<\/li>\n<li> It can be configured to trigger builds automatically by time and\/or changeset (i.e. if a new changeset is detected in the Subversion repository for the project, a new build is triggered).<\/li>\n<li> It reports on build status. If the build is broken, it can be configured to alert individuals by email.<\/li><\/ol>\n<p>The above screenshot gives an example of what a main page for Jenkins CI (or any CI tool) may look like. It can be configured to allow logins at various levels and on a per-project basis. This main page lists all the projects that are currently active, along with a status (a few details about the build) and some configuration links on the side. These links may not be available to a general user.\n<\/p><p>Clicking any project (\"job\") links to further details on the build history and status. This image provides us details on what the overview screen in the CI environment might look like, but it is at the detailed project level that we see the real benefit of packaging that can be performed by a well setup CI environment.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"What.27s_so_great_about_a_CI_build.3F\">What's so great about a CI build?<\/span><\/h2>\n<h3><span class=\"mw-headline\" id=\"Tracing_of_builds_to_a_changeset\">Tracing of builds to a changeset<\/span><\/h3>\n<p>Okay, so I\u2019m starting to sound repetitive, but tracing is a good thing, and with this setup I can trace all over the place! With the entire process in place \u2014 from standard operating procedures to work instructions and from use cases and requirements to tickets and changests \u2014 how do we know that the team members working on a project are actually following procedure? The CI environment, at least with regard to the ongoing development of code, gives us a single point of view for all other activities. From here we can see changesets, tickets, build status, and test coverage. Using the proper add-ons, we can even gain insight into the quality of the code that is being developed.\n<\/p><p>To pull this off, of course, we need to use our ticketing system wisely. With Redmine, or just about any other good ticketing system, we can capture elements of software requirements and software design as parent tickets. These parent tickets have one to many sub-tickets, which themselves can have sub-tickets. A parent ticket may not be closed or marked complete until a child ticket is completed.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Immediate_feedback\">Immediate feedback<\/span><\/h3>\n<p>At its most basic level, Jenkins CI only does one thing: it runs whatever scripts we tell it to. The power of Jenkins CI is that we can tell it to run whatever we want, log the outcome, keep build artifacts, run third-party evaluation tools, and report on results. With Subversion integration, Jenkins CI will display the changeset relevant to a particular build. It can be configured to generate a build at whatever interval we want (nightly, hourly, every time there is a code commit, etc.).\n<\/p><p>Personally, every time I do any code commit of significance, one of the first things I do is check the CI build for success. If I\u2019ve broken the build, I get to work on correcting the problem (and if I cannot correct the problem quickly, I roll my changeset out so that the CI build continues to work until I\u2019ve fixed the issue).\n<\/p><p>Jenkins can be configured to email team members on build results, and it may be useful to set it up so that developers are emailed should a build break.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Central_build_location\">Central build location<\/span><\/h3>\n<p>The build artifacts of your project, in general, should not be a part of the repository (there are exceptions to this rule). Build artifacts belong in your continuous integration build tool, where they can be viewed and used by anyone on the team who needs them. These artifacts include test results, compiled libraries, and executables. Too often a released build is created locally on some developer\u2019s machine. This is a serious problem since we have no good way of knowing what files were actually used to create that build. Was there a configuration change? A bug introduced? An incorrect file version?\n<\/p><p>While developers have good reason to generate and test build locally, a formal build used for testing (or, more importantly, release) must never be created locally. Never.\n<\/p><p>Build artifacts are not checked in to the source control repository for a number of reasons, but the biggest reason is because we never want to make assumptions about the environment in which those items were built. The build artifacts should instead remain in our CI environment, where we know the conditions within which the build was generated.\n<\/p><p>Also, because these builds remain easily accessible and labeled in the CI build environment, any team member can easily access any given build. In particular, it may become necessary to use a specific build to recreate an issue in a build that has been released for internal or external use. Because we know the label of the build (the version number given to it) as well as the repository changeset number of the build (because our build and install scripts include it), we know precisely which build to pull from the CI build server to recreate the necessary conditions.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Unit_tests_are_run_over_and_over_.28and_over.29\">Unit tests are run over and over (and over)<\/span><\/h3>\n<p>Developers should do whatever they can to keep the CI build from breaking. Of course, this doesn\u2019t always work well. I\u2019ve broken the CI build countless times for a number of reasons:\n<\/p>\n<ul><li> I forgot to add a necessary library or new file.<\/li>\n<li> I forgot to commit a configuration change.<\/li>\n<li> I accidentally included a change in my changeset.<\/li>\n<li> It worked locally but not when built on the CI build server (this is why the CI build server should, as much as possible, mimic the production environment).<\/li>\n<li> Unit tests worked locally but not on the CI build server because of some environmental difference.<\/li><\/ul>\n<p>If not for a CI build environment with good unit tests, such problems would only be discovered at a later time or by some other frustrated team member. In this regard, the CI build saves us from many headaches.\n<\/p><p>The most difficult software defects to fix (much less, find) are the ones that do not happen consistently. Database locking issues, memory issues, and race conditions can result in such defects. These defects are serious, but if we never detect them, how can we fix them?\n<\/p><p>It\u2019s a good idea to have unit tests that go above and beyond what we traditionally think of as unit tests and perhaps go several steps further, such as automating functional testing. This is another one of those areas where team members often (incorrectly) feel that there is not sufficient time to do all the work.\n<\/p><p>With Jenkins running all of these tests every time a build is performed, we sometimes encounter situations where a test fails suddenly for no apparent reason. It worked before, an hour ago, and there has not been any change to the code, so what caused it to fail this time? Pay attention, because this WILL happen.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Integration_with_other_nice-to-haves.2C_such_as_Findbugs.2C_PMD.2C_and_Cobertura\">Integration with other nice-to-haves, such as Findbugs, PMD, and Cobertura<\/span><\/h3>\n<p>Without going into too much detail, there are great tools out there that can be used with Jenkins to evaluate the code for potential bugs, bad coding practices, and testing coverage. These tools definitely come in handy. Use them.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Releasing_software\">Releasing software<\/span><\/h2>\n<p>When software is released, it is typically given some kind of version number (e.g., 1.0). This is good, but it doesn\u2019t tell us the specifics of what went into that build. It\u2019s a good idea to include the Subversion changeset number somewhere in the release so that we always know EXACTLY what went into the build. I would include a build.xml (or build.prop) file somewhere that includes the version number of the release, the Subversion changeset number and the date of the build. As far as the last two values, these can (and should) be generated automatically by your build scripts.\n<\/p><p>As far as actually using Subversion within Linux\/Unix, all commands are available from the command line. When working in Windows, I really like using TortoiseSVN. It integrates with Windows File Explorer, showing icons that indicate the status of any versioned file. It also provides a nice interface for viewing file differences (even differences of your Word documents) and repository history.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Ticketing_and_issue_tracing\">Ticketing and issue tracing<\/span><\/h2>\n<p>For too long we\u2019ve thought of our ticketing systems as \"bug trackers.\" One of the previously most popular open-source tools, Bugzilla, even used the word \"bug\" in its name. But issue tracking does not need to imply that it is only useful for tracking software defects. On the contrary, it can be used for everything in software design and development, from addressing documentation needs to capturing software requirements and handling software defect reporting.\n<\/p><p>On that note, I would like to add something that may require an entire post. I think it might be best to get away from using standard documents for the capture of software use cases, requirements, hazards, and so on. By capturing everything related to a software project in our issue tracking tool, we can leverage the power of a tool like Trac or Redmine to enhance team collaboration and project tracing. But I won\u2019t bite off more than I can chew right now.\n<\/p><p>When I first began writing all of these thoughts of mine down, I was going to use Trac as my example (<a rel=\"external_link\" class=\"external free\" href=\"http:\/\/trac.edgewall.org\/\" target=\"_blank\">http:\/\/trac.edgewall.org\/<\/a>). Trac is a great tool, but there\u2019s something better now, and that something is Redmine (<a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.redmine.org\/\" target=\"_blank\">http:\/\/www.redmine.org\/<\/a>).\n<\/p><p>The principal shortcoming of Trac is the fact that it doesn\u2019t lend itself well (at all) to handling multiple projects. One installation of Trac can be integrated with only a single Subversion repository, and the ticketing system can only handle a single project. I still like the way Trac can be used to group tickets into sprints, but by using sub-projects in Redmine, a similar grouping can be achieved. In the past, if a tool was used at all, we used Bugzilla or Clearquest to handle our issue tracking. These tools were very good at the time, but they did not integrate well with other tools, nor did they include features like wikis, calendars, or Gantt charts. (Admittedly, I have not used Clearquest in many years, so I really have no idea whether or not it has since addressed some of these needs.)\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Redmine\">Redmine<\/span><\/h3>\n<p>So what\u2019s so great about Redmine?\n<\/p>\n<ol><li>With the power of the wiki, your documents maintain all of your project management details, work instructions, use cases, requirements, and so on. Again, I think this information can be placed into the wiki, but that may be a step that not everyone is comfortable taking.<\/li>\n<li>That said, all developer setup, lessons learned, and other informal notes can be placed in the wiki. One time I spent nearly four days tracking down a very strange defect. By the time I finally figured it all out I had learned a lot about a very strange issue that others were surely to encounter. I created a wiki page explaining the issue.<\/li>\n<li>Another power feature of the wiki is the fact that with Redmine (and Trac) we can link not only to other wiki pages but also to tickets (issues), projects, sub-projects, and Subversion changesets. Again, more tracing. Nice.<\/li>\n<li>With Subversion and Redmine integrated I can link back and forth between the two. Those work instructions explaining to the team how we will make use of our procedures should explain that no ticket can be closed without a link to a Subversion changeset (unless, of course, the ticket is rejected). Redmine can be configured to search for keywords in your Subversion changeset commit. For example, if I am checking in several files that address issue #501, I might put a comment like this: \"Corrected such and such. This fixes #501.\" We can configure Redmine to look for that word \"fixes\" and use it. Redmine may use that word as a flag to close the ticket and link to the changeset that was created when I did that commit. Likewise, when we view your Subversion history, we will see \"#501\" attached to the changeset as a link to the ticket. The tracing works both ways\u2026 Beautiful!<\/li>\n<li>It has multiple project handling and integration with different Subversion repositories. This is a major reason why I (and others) switched to Redmine. Trac was great, but it only handled a single project. Redmine, with its handling of multiple projects, can be used corporate-wide for all development, and each project can be tied to a different Subversion repository. Additionally, a single project can have multiple sub-projects. This gives us the flexibility to use sub-projects for sprints, specific branched versions, and so on.<\/li>\n<li>With Jenkins integrated, I don\u2019t have to leave the wiki to see how my CI builds look. Not only that, I can link to a specific CI build from any page within the wiki or ticketing system.<\/li>\n<li>Everything can be configured in Redmine. Yes, EVERYTHING. We can even configure the flow of tickets.<\/li><\/ol>\n<h3><span class=\"mw-headline\" id=\"The_issue_tracking_system\">The issue tracking system<\/span><\/h3>\n<p>I propose that it is not enough to simply leave functional requirements in the software requirements specification document. This does not provide sufficient tracing, nor does it provide a clear path from idea to functional code. Here are the steps that I suggest:\n<\/p>\n<ol><li>All requirements and software design items are entered as tickets. For now they are simply high-level tickets with no child tickets.<\/li>\n<li>The development team, organized by a lead developer, breaks down each high-level ticket into as many child tickets as necessary. Using the ticketing system, we set up relationships so that the parent ticket (the requirement itself) cannot be closed until all child tickets are completed. (Note: It may be a good idea to require corresponding unit tests with each ticket.)<\/li>\n<li>Hazards (and I'm not doing to bother an explanation of hazard and risk analysis in this article) are mitigated by a combination of documentation, requirements, and tests. We can leverage our ticketing system to capture our hazards and provide tracing in much the same way as with requirements. This does not remove the need for a traceability matrix, but it does enhance our ability to create and maintain it. (As a side note, I think it would be great to use the Redmine wiki for use cases, requirements, hazard analysis, software design documents, and traceability matrices, thereby allowing for linking within, but this may be a hard sell for now).<\/li>\n<li>Not all requirements are functional code requirements. Many are documentation and\/or quality requirements. These should be captured in the same ticketing system. Use the ability of the system to label the type of ticket to handle the fact that there are different categories. By doing this, even documentation requirements are traceable in our system.<\/li>\n<li>I'm not suggesting that the tickets will be locked down this early, not for a moment! Tickets are created, closed, and modified throughout project design and the development process. Our project plan (created before we started writing code) explains to us which tickets need to be done when, focusing more on the highest level tickets. That said, I find it best to use some sort of iterative approach (and allow the development team to use sub-iterations, or \"sprints\").<\/li><\/ol>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-WPContIntAug11-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-WPContIntAug11_1-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578\" target=\"_blank\">\"Continuous integration\"<\/a>. <i>Wikipedia<\/i>. Wikimedia Foundation, Inc. 28 August 2011<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578\" target=\"_blank\">https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Continuous+integration&rft.atitle=Wikipedia&rft.date=28+August+2011&rft.pub=Wikimedia+Foundation%2C+Inc&rft_id=https%3A%2F%2Fen.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DContinuous_integration%26oldid%3D447106578&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<\/ol><\/div>\n\n<!-- \nNewPP limit report\nCached time: 20190104224853\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.131 seconds\nReal time usage: 0.954 seconds\nPreprocessor visited node count: 680\/1000000\nPreprocessor generated node count: 11573\/1000000\nPost\u2010expand include size: 4132\/2097152 bytes\nTemplate argument size: 1497\/2097152 bytes\nHighest expansion depth: 12\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 43.944 1 - Template:Reflist\n100.00% 43.944 1 - -total\n 82.63% 36.311 1 - Template:Cite_web\n 71.66% 31.491 1 - Template:Citation\/core\n 7.83% 3.442 2 - Template:Citation\/make_link\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8683-0!*!0!!en!5!* and timestamp 20190104224852 and revision id 25235\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","8aa7cf5a1a2f18bd7ab6b7269eff4787_images":["https:\/\/upload.wikimedia.org\/wikipedia\/commons\/3\/33\/Continuous-integration-dhf.jpg"],"8aa7cf5a1a2f18bd7ab6b7269eff4787_timestamp":1546642132,"613f1316ca7e0f1ba75417bfe2747d39_type":"article","613f1316ca7e0f1ba75417bfe2747d39_title":"Introduction","613f1316ca7e0f1ba75417bfe2747d39_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction","613f1316ca7e0f1ba75417bfe2747d39_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Introduction\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\nContents\n\n1 Definition \n2 Continuous integration on regulated projects \n3 Continuous integration is the process \n4 References \n\n\n\nDefinition \nTo start with, we need to define continuous integration. In August 2011, Wikipedia offered the following definition:\n\nIn software engineering, continuous integration (CI) implements continuous processes of applying quality control \u2014 small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.[1]\nThe term first emerged at the turn of the century out of Martin Fowler and Kent Beck's writings on the topic. Fowler's 2000 paper[2] is an often-cited source of information on the subject. Beck's 1999 book Extreme Programming Explained,[3] the original reference for Extreme Programming, also introduced the term.\nThe working definition given by Wikipedia above is good because it helps to eliminate the mistaken idea that continuous integration is a task within the larger picture (i.e., when people think of continuous integration, they tend to think of continuous integration builds and not the entire process). Continuous integration is a process that encompasses software development efforts and not simply the act of integrating and building code. This is very important to take note of!\n\nContinuous integration on regulated projects \nHow can continuous integration be utilized in the tightly regulated world of software medical devices? Let me begin with a story.\nWhen it comes to regulated environments, such as the regulation enforced by the FDA on medical device software, we tend to focus on standard operating procedures (SOPs). Often these SOPs become so rigid that they tie our hands, preventing agile (lowercase a) software implementation and introducing bureaucracy for bureaucracy's sake. Ultimately, those standard operating procedures that took so long to create and (attempt to) enforce become so cumbersome that all other work takes secondary attention to the almighty process. The good news is that someone was trying to think of the process (if there is any good news to be found). The bad news is that nobody (including the author) remembers exactly what those procedures say. This is where an intelligent continuous integration approach to all software development can be a silver bullet.\nMy first experience working on medical device software came in 2002. My previous employer, an exciting venture of the dot-com era, failed to provide me the millions of dollars that I expected. Still somewhat fresh out of college, I was hit by reality: those 100,000 shares of stock weren\u2019t going to be worth anything, and I would continue driving a 1998 Dodge Stratus for a few more years.\nFaced with my first humbling experience in the unemployment line, I was eager to accept the first job that came along, and soon enough I found myself working on a blood bank project performing software quality assurance. I\u2019m not sure what was more humbling to an arrogant young software developer: the unemployment line or being forced to write test scripts. But it was a job, and being one of thousands of software developers looking for work, I took it.\nOn day one at my new job I learned something bizarre: the software we wrote would be audited and controlled by a set of standards defined by the FDA. \"The FDA,\" I asked, \"as in The Food and Drug Administration?\" Yep. That FDA. I was told to sit in my cubicle and read something called the CFR, focusing specifically on parts 11 and 820. It was long and boring and strange sounding, and I was annoyed. I yawned incessantly as I forced my way through it.\nMy next task was to read a bunch of standard operating procedures (SOPs). Upon reading an SOP I took a test answering a few simple questions about it. It was graded and signed and placed in a permanent file somewhere as proof that I knew the SOP. At this point I promptly forgot what the SOP said.\nMy job was simple. I was to review use cases, write test scripts for those use cases (both manual and automated), and run the scripts. When I finished one task, I moved on to the next (that task being whatever my boss told me to work on). Soon enough the SOPs I had read during my first few weeks of employment were a distant memory. I had no reason to revisit them.\nBut perhaps I should have. Remember how I signed a test saying that I read and understood the SOP? About six months into my employment, it came time for an internal audit of the project. The purpose of this audit was to perform activities similar to those which might occur during an actual FDA audit for a 510k. I was pulled into a room with the auditors and interrogated.\nThe auditor asked me the first question: \"So Matt, when you do your work, how do you know what to do?\"\nThe question seemed odd, but I responded politely: \"Uh, well, I guess I do whatever my boss tells me to do.\"\nWrong answer.\nThe auditor continued: \"No, what I mean is, how do you know what you are supposed to create?\"\nI began to squirm a bit: \"Um, because my boss tells me what to do\u2026 I read the use case and requirements, and I write the test.\"\nThis was not going well.\nThe bizarre questioning continued for an uncomfortably long time until finally the auditor gave up and told me that I could return to my cubicle. For a brief period of time, I was relieved. Then the project manager caught wind of my inarticulate question and answer session.\nI was in trouble.\n\nContinuous integration is the process \nAre we talking about standard operating procedures or continuous integration? We're talking about both! Continuous integration is much more than simply contributing to a shared repository and ensuring software build integrity. Continuous integration is a process that leads to a cohesive team with logical procedures. Continuous integration means that no member of the team, from management to development, may work in a vacuum. The process by which high-quality software is engineered is a process that involves all roles, and it requires more than simple memorization of some procedures that were read once time. The procedures are an integral part of the daily work activities. More importantly, the procedures make sense.\n\nReferences \n\n\n\u2191 \"Continuous integration\". Wikipedia. Wikimedia Foundation, Inc. 28 August 2011. https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578 . Retrieved 27 April 2016 .   \n\n\u2191 Fowler, M. (01 May 2006). \"Continuous Integration\". MartinFowler.com. http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html . Retrieved 27 April 2016 .   \n\n\u2191 Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional. pp. 224. ISBN 0201616416.   \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 18:35.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 608 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","613f1316ca7e0f1ba75417bfe2747d39_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Introduction skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Introduction<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n\n\n<h2><span class=\"mw-headline\" id=\"Definition\">Definition<\/span><\/h2>\n<p>To start with, we need to define <b>continuous integration<\/b>. In August 2011, Wikipedia offered the following definition:\n<\/p>\n<blockquote>In software engineering, continuous integration (CI) implements continuous processes of applying quality control \u2014 small pieces of effort, applied frequently. Continuous integration aims to improve the quality of software, and to reduce the time taken to deliver it, by replacing the traditional practice of applying quality control after completing all development.<sup id=\"rdp-ebb-cite_ref-WPContIntAug11_1-0\" class=\"reference\"><a href=\"#cite_note-WPContIntAug11-1\" rel=\"external_link\">[1]<\/a><\/sup><\/blockquote>\n<p>The term first emerged at the turn of the century out of Martin Fowler and Kent Beck's writings on the topic. Fowler's 2000 paper<sup id=\"rdp-ebb-cite_ref-FowlerCI00_2-0\" class=\"reference\"><a href=\"#cite_note-FowlerCI00-2\" rel=\"external_link\">[2]<\/a><\/sup> is an often-cited source of information on the subject. Beck's 1999 book <i>Extreme Programming Explained<\/i>,<sup id=\"rdp-ebb-cite_ref-BeckExtreme99_3-0\" class=\"reference\"><a href=\"#cite_note-BeckExtreme99-3\" rel=\"external_link\">[3]<\/a><\/sup> the original reference for Extreme Programming, also introduced the term.\n<\/p><p>The working definition given by Wikipedia above is good because it helps to eliminate the mistaken idea that continuous integration is a task within the larger picture (i.e., when people think of continuous integration, they tend to think of continuous integration builds and not the entire process). Continuous integration is a process that encompasses software development efforts and not simply the act of integrating and building code. This is very important to take note of!\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Continuous_integration_on_regulated_projects\">Continuous integration on regulated projects<\/span><\/h2>\n<p>How can continuous integration be utilized in the tightly regulated world of software medical devices? Let me begin with a story.\n<\/p><p>When it comes to regulated environments, such as the regulation enforced by the FDA on medical device software, we tend to focus on standard operating procedures (SOPs). Often these SOPs become so rigid that they tie our hands, preventing agile (lowercase a) software implementation and introducing bureaucracy for bureaucracy's sake. Ultimately, those standard operating procedures that took so long to create and (attempt to) enforce become so cumbersome that all other work takes secondary attention to the almighty process. The good news is that someone was trying to think of the process (if there is any good news to be found). The bad news is that nobody (including the author) remembers exactly what those procedures say. This is where an intelligent continuous integration approach to all software development can be a silver bullet.\n<\/p><p>My first experience working on medical device software came in 2002. My previous employer, an exciting venture of the dot-com era, failed to provide me the millions of dollars that I expected. Still somewhat fresh out of college, I was hit by reality: those 100,000 shares of stock weren\u2019t going to be worth anything, and I would continue driving a 1998 Dodge Stratus for a few more years.\n<\/p><p>Faced with my first humbling experience in the unemployment line, I was eager to accept the first job that came along, and soon enough I found myself working on a blood bank project performing software quality assurance. I\u2019m not sure what was more humbling to an arrogant young software developer: the unemployment line or being forced to write test scripts. But it was a job, and being one of thousands of software developers looking for work, I took it.\n<\/p><p>On day one at my new job I learned something bizarre: the software we wrote would be audited and controlled by a set of standards defined by the FDA. \"The FDA,\" I asked, \"as in The Food and Drug Administration?\" Yep. That FDA. I was told to sit in my cubicle and read something called the CFR, focusing specifically on parts 11 and 820. It was long and boring and strange sounding, and I was annoyed. I yawned incessantly as I forced my way through it.\n<\/p><p>My next task was to read a bunch of standard operating procedures (SOPs). Upon reading an SOP I took a test answering a few simple questions about it. It was graded and signed and placed in a permanent file somewhere as proof that I knew the SOP. At this point I promptly forgot what the SOP said.\n<\/p><p>My job was simple. I was to review use cases, write test scripts for those use cases (both manual and automated), and run the scripts. When I finished one task, I moved on to the next (that task being whatever my boss told me to work on). Soon enough the SOPs I had read during my first few weeks of employment were a distant memory. I had no reason to revisit them.\n<\/p><p>But perhaps I should have. Remember how I signed a test saying that I read and understood the SOP? About six months into my employment, it came time for an internal audit of the project. The purpose of this audit was to perform activities similar to those which might occur during an actual FDA audit for a 510k. I was pulled into a room with the auditors and interrogated.\n<\/p><p>The auditor asked me the first question: \"So Matt, when you do your work, how do you know what to do?\"\n<\/p><p>The question seemed odd, but I responded politely: \"Uh, well, I guess I do whatever my boss tells me to do.\"\n<\/p><p>Wrong answer.\n<\/p><p>The auditor continued: \"No, what I mean is, how do you know what you are supposed to create?\"\n<\/p><p>I began to squirm a bit: \"Um, because my boss tells me what to do\u2026 I read the use case and requirements, and I write the test.\"\n<\/p><p>This was not going well.\n<\/p><p>The bizarre questioning continued for an uncomfortably long time until finally the auditor gave up and told me that I could return to my cubicle. For a brief period of time, I was relieved. Then the project manager caught wind of my inarticulate question and answer session.\n<\/p><p>I was in trouble.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Continuous_integration_is_the_process\">Continuous integration <b>is<\/b> the process<\/span><\/h2>\n<p>Are we talking about standard operating procedures or continuous integration? We're talking about both! Continuous integration is much more than simply contributing to a shared repository and ensuring software build integrity. Continuous integration is a process that leads to a cohesive team with logical procedures. Continuous integration means that no member of the team, from management to development, may work in a vacuum. The process by which high-quality software is engineered is a process that involves all roles, and it requires more than simple memorization of some procedures that were read once time. The procedures are an integral part of the daily work activities. More importantly, the procedures make sense.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-WPContIntAug11-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-WPContIntAug11_1-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578\" target=\"_blank\">\"Continuous integration\"<\/a>. <i>Wikipedia<\/i>. Wikimedia Foundation, Inc. 28 August 2011<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578\" target=\"_blank\">https:\/\/en.wikipedia.org\/w\/index.php?title=Continuous_integration&oldid=447106578<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Continuous+integration&rft.atitle=Wikipedia&rft.date=28+August+2011&rft.pub=Wikimedia+Foundation%2C+Inc&rft_id=https%3A%2F%2Fen.wikipedia.org%2Fw%2Findex.php%3Ftitle%3DContinuous_integration%26oldid%3D447106578&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FowlerCI00-2\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FowlerCI00_2-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Fowler, M. (01 May 2006). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html\" target=\"_blank\">\"Continuous Integration\"<\/a>. <i>MartinFowler.com<\/i><span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html\" target=\"_blank\">http:\/\/www.martinfowler.com\/articles\/continuousIntegration.html<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Continuous+Integration&rft.atitle=MartinFowler.com&rft.aulast=Fowler%2C+M.&rft.au=Fowler%2C+M.&rft.date=01+May+2006&rft_id=http%3A%2F%2Fwww.martinfowler.com%2Farticles%2FcontinuousIntegration.html&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-BeckExtreme99-3\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-BeckExtreme99_3-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation book\">Beck, K. (1999). <i>Extreme Programming Explained: Embrace Change<\/i>. Addison-Wesley Professional. pp. 224. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 0201616416.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Extreme+Programming+Explained%3A+Embrace+Change&rft.aulast=Beck%2C+K.&rft.au=Beck%2C+K.&rft.date=1999&rft.pages=pp.%26nbsp%3B224&rft.pub=Addison-Wesley+Professional&rft.isbn=0201616416&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<\/ol><\/div>\n\n<!-- \nNewPP limit report\nCached time: 20190104224852\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.107 seconds\nReal time usage: 0.125 seconds\nPreprocessor visited node count: 1931\/1000000\nPreprocessor generated node count: 16023\/1000000\nPost\u2010expand include size: 11094\/2097152 bytes\nTemplate argument size: 3573\/2097152 bytes\nHighest expansion depth: 13\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 100.618 1 - -total\n100.00% 100.618 1 - Template:Reflist\n 74.76% 75.221 3 - Template:Citation\/core\n 55.86% 56.206 2 - Template:Cite_web\n 31.16% 31.355 1 - Template:Cite_book\n 8.13% 8.180 1 - Template:Citation\/identifier\n 5.82% 5.854 5 - Template:Citation\/make_link\n 1.92% 1.927 2 - Template:Hide_in_print\n 1.89% 1.898 1 - Template:Only_in_print\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8681-0!*!0!!en!*!* and timestamp 20190104224852 and revision id 25232\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","613f1316ca7e0f1ba75417bfe2747d39_images":[],"613f1316ca7e0f1ba75417bfe2747d39_timestamp":1546642131,"fb5fecbcef204bee669859f6511678d4_type":"article","fb5fecbcef204bee669859f6511678d4_title":"Further defining medical device software","fb5fecbcef204bee669859f6511678d4_url":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software","fb5fecbcef204bee669859f6511678d4_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tLII:Medical Device Software Development with Continuous Integration\/Defining Medical Device Software\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\t-----Return to the beginning of this guide-----\nWhat is medical device software? \nGlobally, when writing software for medical purposes, that software may or may not be subject to regulatory scrutiny. In the U.S., we may or may not be required to submit an application for Food and Drug Administration (FDA) 510(k) Premarket Notification. What does this mean? How do we know? Its all a little confusing. It was time to consider a series of articles on the subject.\nRegarding medical device software, the global IEC 62304 standard on the software life cycle processes of medical device software states it's a \"software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right.\"[1] In the U.S., the FDA states that \"any software that meets the legal definition of a [medical] device\" is considered medical device software.[2] A similar \"software can be a medical device\" interpretation was also made by the European Union in 2007 with an update to its European Medical Devices Directive, when \"used specifically for diagnostic and\/or therapeutic purposes.\"[3]\nAll these definitions refer to such software as a medical device. I also chose to navigate through 21 CFR Part 820.30 on design controls in quality system regulation; however, this regulatory code also deals with medical device classification, something that should be left to the FDA and other regulatory entities, not a design team working on the quality system. We are not fully qualified to determine whether or not we are working on a medical device, let alone what classification it is. Left on our own, we can likely come up with many great excuses as to why we think our product is not a medical device!\n\nView as a medical device \nIn 21 CFR Part 820.30 on design controls, we are presented with the following[4]:\n\n(a) General. (1) Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.\n(2) The following class I devices are subject to design controls:\n(i) Devices automated with computer software; and\n(ii) The devices listed in the following chart. \n\n\n\n\nSection\r\n\n\nDevice\r\n\n\n\n 868.6810\n\n Catheter, Tracheobronchial Suction.\n\n\n 878.4460\n\n Glove, Surgeon\u2019s.\n\n\n 880.6760\n\n Restraint, Protective.\n\n\n 892.5650\n\nSystem, Applicator, Radionuclide, Manual.\n\n\n892.5740\n\nSource, Radionuclide Teletherapy.\n\n\nIn Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations, author Thomas H. Faris offers us a definition of a medical device:\n\nMedical Device: Any equipment, instrument, apparatus, or other tool that is used to perform or assist with prevention, diagnosis, or treatment of a disease or injury. As an industrial term of art, a \u201cmedical device\u201d typically relates to a product that the FDA or other regulatory authority identifies as a regulated device for medical use.[5]\nI\u2019ve been contemplating a detailed writeup on this subject, but I haven\u2019t had a good idea of where to begin, especially since my own regulatory experience is, at best, limited. Today I stumbled upon this article on the subject over at MEDS Magazine. Author Bruce Swope offers a little bit of insight on the three medical device classifications:\n\nGenerally, these three classes are determined by the patient risk associated with your device. Typically, low-risk products like tongue depressors are defined as Class I devices, and high-risk items like implantable defibrillators are defined as Class III devices. The marketing approval process is usually determined based on a combination of the class of the device and whether the product is substantially equivalent to an existing FDA-approved product. If the device is a Class I or a subset of Class II and is equivalent to a device marketed before May 28, 1976, then it may be classified as an Exempt Device. A 510(k) is a pre-marketing submission made to the FDA that demonstrates that the device is as safe and effective (substantially equivalent) to a legally marketed device that is not subject to Pre-market Approval (PMA). For the purpose of 510(k) decision-making, the term \u201cpre-amendment device\u201d refers to products legally marketed in the U.S. before May 28, 1976 and which have not been:\n significantly changed or modified since then; and\n for which a regulation requiring a PMA application has not been published by the FDA.\nPMA requirements apply to Class III pre-amendment devices, \u201ctransitional devices\u201d and \u201cpost-amendment\u201d devices. PMA is the most stringent type of product marketing application required by the FDA. The device maker must receive FDA approval of its PMA application prior to marketing the device. PMA approval is based on the FDA\u2019s determination that the application contains sufficient valid scientific evidence to ensure that the device is safe and effective for its intended use(s). For some 510(k) submissions and most PMA applications, clinical performance data is required to obtain clearance to market the device. In these cases, trials must be conducted in accordance with the FDA\u2019s Investigational Device Exemption (IDE) regulation.[6]\nUltimately, however, we cannot classify our own medical device software. That is the job of the FDA, which has offered guidance and driven regulation on medical software as a medical device over the years.[7][8][9]\n\nReferences \n\n\n\u2191 International Electrotechnical Commission (2006). \"Medical device software \u2013 Software life cycle processes\" (PDF). International Standard IEC 62304, First Edition 2006-05. International Electrotechnical Commission. https:\/\/webstore.iec.ch\/preview\/info_iec62304%7Bed1.0%7Den_d.pdf . Retrieved 27 April 2016 .   \n\n\u2191 Murray Jr., J.F. (March 2010). \"CDRH Regulated Software: An Introduction\" (PDF). U.S. Food and Drug Administration. http:\/\/www.fda.gov\/downloads\/Training\/CDRHLearn\/UCM209129.pdf . Retrieved 27 April 2016 .   \n\n\u2191 \"Directive 2007\/47\/ED of the European Parliament and of the Council\" (PDF). Official Journal of the European Union. European Union. 5 September 2007. http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF . Retrieved 27 April 2016 .   \n\n\u2191 \"Title 21--Food and Drugs, Part 820--Quality System Regulation, Sec. 820.30 Design controls\". CFR - Code of Federal Regulations Title 21. Food and Drug Administration. 21 August 2015. https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30 . Retrieved 27 April 2016 .   \n\n\u2191 Faris, T.H. (2006). Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations. ASQ Quality Press. p. 118. ISBN 0873896742.   \n\n\u2191 Swope, B. (July 2011). \"Executive Overview of FDA Medical Device Approval Requirements\". MEDS Magazine. The RTC Group. http:\/\/medsmagazine.com\/2011\/07\/executive-overview-of-fda-medical-device-approval-requirements\/ . Retrieved 27 April 2016 .   \n\n\u2191 Vogel, D.A. (2011). \"Chapter 3: The FDA Software Validation Regulations and Why You Should Validate Software Anyway\". Medical Device Software Verification, Validation, and Compliance. Boston, MA: Artech House. pp. 27\u201336. ISBN 9781596934238. https:\/\/books.google.com\/books?id=LYxH-zUSOTgC&pg=PA27 .   \n\n\u2191 Office of Device Evaluation, Center for Devices and Radiological Health (9 September 1999). \"Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices\" (PDF). U.S. Food and Drug Administration. http:\/\/www.fda.gov\/downloads\/MedicalDevices\/...\/ucm073779.pdf . Retrieved 26 April 2016 .   \n\n\u2191 Center for Devices and Radiological Health (11 May 2005). \"Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices\". U.S. Food and Drug Administration. http:\/\/www.fda.gov\/RegulatoryInformation\/Guidances\/ucm089543.htm . Retrieved 26 April 2016 .   \n\n\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software<\/a>\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tLII\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 27 April 2016, at 18:37.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 589 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","fb5fecbcef204bee669859f6511678d4_html":"<body class=\"mediawiki ltr sitedir-ltr ns-202 ns-subject page-LII_Medical_Device_Software_Development_with_Continuous_Integration_Defining_Medical_Device_Software skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">LII:Medical Device Software Development with Continuous Integration\/Defining Medical Device Software<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div align=\"center\">-----Return to <a href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\" title=\"LII:Medical Device Software Development with Continuous Integration\" target=\"_blank\" class=\"wiki-link\" data-key=\"3cb3f79774b24a8afa847a72c56c4835\">the beginning<\/a> of this guide-----<\/div>\n<h2><span class=\"mw-headline\" id=\"What_is_medical_device_software.3F\">What is medical device software?<\/span><\/h2>\n<p>Globally, when writing software for medical purposes, that software may or may not be subject to regulatory scrutiny. In the U.S., we may or may not be required to submit an application for Food and Drug Administration (FDA) 510(k) Premarket Notification. What does this mean? How do we know? Its all a little confusing. It was time to consider a series of articles on the subject.\n<\/p><p>Regarding medical device software, the global IEC 62304 standard on the software life cycle processes of medical device software states it's a \"software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right.\"<sup id=\"rdp-ebb-cite_ref-IEC62304_1-0\" class=\"reference\"><a href=\"#cite_note-IEC62304-1\" rel=\"external_link\">[1]<\/a><\/sup> In the U.S., the FDA states that \"any software that meets the legal definition of a [medical] device\" is considered medical device software.<sup id=\"rdp-ebb-cite_ref-MurrayCDRH10_2-0\" class=\"reference\"><a href=\"#cite_note-MurrayCDRH10-2\" rel=\"external_link\">[2]<\/a><\/sup> A similar \"software can be a medical device\" interpretation was also made by the European Union in 2007 with an update to its European Medical Devices Directive, when \"used specifically for diagnostic and\/or therapeutic purposes.\"<sup id=\"rdp-ebb-cite_ref-2007.2F47.2FEC_3-0\" class=\"reference\"><a href=\"#cite_note-2007.2F47.2FEC-3\" rel=\"external_link\">[3]<\/a><\/sup>\n<\/p><p>All these definitions refer to such software as a medical device. I also chose to navigate through 21 CFR Part 820.30 on design controls in quality system regulation; however, this regulatory code also deals with medical device classification, something that should be left to the FDA and other regulatory entities, not a design team working on the quality system. We are not fully qualified to determine whether or not we are working on a medical device, let alone what classification it is. Left on our own, we can likely come up with many great excuses as to why we think our product is not a medical device!\n<\/p>\n<h3><span class=\"mw-headline\" id=\"View_as_a_medical_device\">View as a medical device<\/span><\/h3>\n<p>In 21 CFR Part 820.30 on design controls, we are presented with the following<sup id=\"rdp-ebb-cite_ref-21CFRPart820.30_4-0\" class=\"reference\"><a href=\"#cite_note-21CFRPart820.30-4\" rel=\"external_link\">[4]<\/a><\/sup>:\n<\/p>\n<blockquote>(a) General. (1) Each manufacturer of any class III or class II device, and the class I devices listed in paragraph (a)(2) of this section, shall establish and maintain procedures to control the design of the device in order to ensure that specified design requirements are met.\n<p>(2) The following class I devices are subject to design controls:\n<\/p><p>(i) Devices automated with computer software; and\n<\/p><p>(ii) The devices listed in the following chart. \n<\/p>\n<table class=\"wikitable sortable\" style=\"\">\n\n<tr>\n<th width=\"20%\">Section<br \/>\n<\/th>\n<th width=\"80%\">Device<br \/>\n<\/th><\/tr>\n<tr>\n<td> 868.6810\n<\/td>\n<td> Catheter, Tracheobronchial Suction.\n<\/td><\/tr>\n<tr>\n<td> 878.4460\n<\/td>\n<td> Glove, Surgeon\u2019s.\n<\/td><\/tr>\n<tr>\n<td> 880.6760\n<\/td>\n<td> Restraint, Protective.\n<\/td><\/tr>\n<tr>\n<td> 892.5650\n<\/td>\n<td>System, Applicator, Radionuclide, Manual.\n<\/td><\/tr>\n<tr>\n<td>892.5740\n<\/td>\n<td>Source, Radionuclide Teletherapy.\n<\/td><\/tr>\n<\/table><\/blockquote>\n<p>In <i>Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations<\/i>, author Thomas H. Faris offers us a definition of a medical device:\n<\/p>\n<blockquote>Medical Device: Any equipment, instrument, apparatus, or other tool that is used to perform or assist with prevention, diagnosis, or treatment of a disease or injury. As an industrial term of art, a \u201cmedical device\u201d typically relates to a product that the FDA or other regulatory authority identifies as a regulated device for medical use.<sup id=\"rdp-ebb-cite_ref-FarisSafe06_5-0\" class=\"reference\"><a href=\"#cite_note-FarisSafe06-5\" rel=\"external_link\">[5]<\/a><\/sup><\/blockquote>\n<p>I\u2019ve been contemplating a detailed writeup on this subject, but I haven\u2019t had a good idea of where to begin, especially since my own regulatory experience is, at best, limited. Today I stumbled upon this article on the subject over at MEDS Magazine. Author Bruce Swope offers a little bit of insight on the three medical device classifications:\n<\/p>\n<blockquote>Generally, these three classes are determined by the patient risk associated with your device. Typically, low-risk products like tongue depressors are defined as Class I devices, and high-risk items like implantable defibrillators are defined as Class III devices. The marketing approval process is usually determined based on a combination of the class of the device and whether the product is substantially equivalent to an existing FDA-approved product. If the device is a Class I or a subset of Class II and is equivalent to a device marketed before May 28, 1976, then it may be classified as an Exempt Device. A 510(k) is a pre-marketing submission made to the FDA that demonstrates that the device is as safe and effective (substantially equivalent) to a legally marketed device that is not subject to Pre-market Approval (PMA). For the purpose of 510(k) decision-making, the term \u201cpre-amendment device\u201d refers to products legally marketed in the U.S. before May 28, 1976 and which have not been:\n<ul><li> significantly changed or modified since then; and<\/li>\n<li> for which a regulation requiring a PMA application has not been published by the FDA.<\/li><\/ul>\nPMA requirements apply to Class III pre-amendment devices, \u201ctransitional devices\u201d and \u201cpost-amendment\u201d devices. PMA is the most stringent type of product marketing application required by the FDA. The device maker must receive FDA approval of its PMA application prior to marketing the device. PMA approval is based on the FDA\u2019s determination that the application contains sufficient valid scientific evidence to ensure that the device is safe and effective for its intended use(s). For some 510(k) submissions and most PMA applications, clinical performance data is required to obtain clearance to market the device. In these cases, trials must be conducted in accordance with the FDA\u2019s Investigational Device Exemption (IDE) regulation.<sup id=\"rdp-ebb-cite_ref-SwopeExec11_6-0\" class=\"reference\"><a href=\"#cite_note-SwopeExec11-6\" rel=\"external_link\">[6]<\/a><\/sup><\/blockquote>\n<p>Ultimately, however, we cannot classify our own medical device software. That is the job of the FDA, which has offered guidance and driven regulation on medical software as a medical device over the years.<sup id=\"rdp-ebb-cite_ref-VogelMed11_7-0\" class=\"reference\"><a href=\"#cite_note-VogelMed11-7\" rel=\"external_link\">[7]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FDAOff99_8-0\" class=\"reference\"><a href=\"#cite_note-FDAOff99-8\" rel=\"external_link\">[8]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FDAGuidance05_9-0\" class=\"reference\"><a href=\"#cite_note-FDAGuidance05-9\" rel=\"external_link\">[9]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist\" style=\"list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-IEC62304-1\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-IEC62304_1-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">International Electrotechnical Commission (2006). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/webstore.iec.ch\/preview\/info_iec62304%7Bed1.0%7Den_d.pdf\" target=\"_blank\">\"Medical device software \u2013 Software life cycle processes\"<\/a> (PDF). <i>International Standard IEC 62304, First Edition 2006-05<\/i>. International Electrotechnical Commission<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/webstore.iec.ch\/preview\/info_iec62304%7Bed1.0%7Den_d.pdf\" target=\"_blank\">https:\/\/webstore.iec.ch\/preview\/info_iec62304%7Bed1.0%7Den_d.pdf<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Medical+device+software+%E2%80%93++Software+life+cycle+processes&rft.atitle=International+Standard+IEC+62304%2C+First+Edition+2006-05&rft.aulast=International+Electrotechnical+Commission&rft.au=International+Electrotechnical+Commission&rft.date=2006&rft.pub=International+Electrotechnical+Commission&rft_id=https%3A%2F%2Fwebstore.iec.ch%2Fpreview%2Finfo_iec62304%257Bed1.0%257Den_d.pdf&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-MurrayCDRH10-2\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-MurrayCDRH10_2-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Murray Jr., J.F. (March 2010). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/Training\/CDRHLearn\/UCM209129.pdf\" target=\"_blank\">\"CDRH Regulated Software: An Introduction\"<\/a> (PDF). U.S. Food and Drug Administration<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.fda.gov\/downloads\/Training\/CDRHLearn\/UCM209129.pdf\" target=\"_blank\">http:\/\/www.fda.gov\/downloads\/Training\/CDRHLearn\/UCM209129.pdf<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=CDRH+Regulated+Software%3A+An+Introduction&rft.atitle=&rft.aulast=Murray+Jr.%2C+J.F.&rft.au=Murray+Jr.%2C+J.F.&rft.date=March+2010&rft.pub=U.S.+Food+and+Drug+Administration&rft_id=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FTraining%2FCDRHLearn%2FUCM209129.pdf&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-2007.2F47.2FEC-3\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-2007.2F47.2FEC_3-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF\" target=\"_blank\">\"Directive 2007\/47\/ED of the European Parliament and of the Council\"<\/a> (PDF). <i>Official Journal of the European Union<\/i>. European Union. 5 September 2007<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF\" target=\"_blank\">http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Directive+2007%2F47%2FED+of+the+European+Parliament+and+of+the+Council&rft.atitle=Official+Journal+of+the+European+Union&rft.date=5+September+2007&rft.pub=European+Union&rft_id=http%3A%2F%2Feur-lex.europa.eu%2FLexUriServ%2FLexUriServ.do%3Furi%3DOJ%3AL%3A2007%3A247%3A0021%3A0055%3Aen%3APDF&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-21CFRPart820.30-4\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-21CFRPart820.30_4-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30\" target=\"_blank\">\"Title 21--Food and Drugs, Part 820--Quality System Regulation, Sec. 820.30 Design controls\"<\/a>. <i>CFR - Code of Federal Regulations Title 21<\/i>. Food and Drug Administration. 21 August 2015<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30\" target=\"_blank\">https:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?fr=820.30<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Title+21--Food+and+Drugs%2C+Part+820--Quality+System+Regulation%2C+Sec.+820.30+Design+controls&rft.atitle=CFR+-+Code+of+Federal+Regulations+Title+21&rft.date=21+August+2015&rft.pub=Food+and+Drug+Administration&rft_id=https%3A%2F%2Fwww.accessdata.fda.gov%2Fscripts%2Fcdrh%2Fcfdocs%2FcfCFR%2FCFRSearch.cfm%3Ffr%3D820.30&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FarisSafe06-5\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FarisSafe06_5-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation book\">Faris, T.H. (2006). <i>Safe and Sound Software: Creating an Efficient and Effective Quality System for Software Medical Device Organizations<\/i>. ASQ Quality Press. p. 118. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 0873896742.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Safe+and+Sound+Software%3A+Creating+an+Efficient+and+Effective+Quality+System+for+Software+Medical+Device+Organizations&rft.aulast=Faris%2C+T.H.&rft.au=Faris%2C+T.H.&rft.date=2006&rft.pages=p.%26nbsp%3B118&rft.pub=ASQ+Quality+Press&rft.isbn=0873896742&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-SwopeExec11-6\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-SwopeExec11_6-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Swope, B. (July 2011). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/medsmagazine.com\/2011\/07\/executive-overview-of-fda-medical-device-approval-requirements\/\" target=\"_blank\">\"Executive Overview of FDA Medical Device Approval Requirements\"<\/a>. <i>MEDS Magazine<\/i>. The RTC Group<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/medsmagazine.com\/2011\/07\/executive-overview-of-fda-medical-device-approval-requirements\/\" target=\"_blank\">http:\/\/medsmagazine.com\/2011\/07\/executive-overview-of-fda-medical-device-approval-requirements\/<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 27 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Executive+Overview+of+FDA+Medical+Device+Approval+Requirements&rft.atitle=MEDS+Magazine&rft.aulast=Swope%2C+B.&rft.au=Swope%2C+B.&rft.date=July+2011&rft.pub=The+RTC+Group&rft_id=http%3A%2F%2Fmedsmagazine.com%2F2011%2F07%2Fexecutive-overview-of-fda-medical-device-approval-requirements%2F&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-VogelMed11-7\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-VogelMed11_7-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation book\">Vogel, D.A. (2011). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=LYxH-zUSOTgC&pg=PA27\" target=\"_blank\">\"Chapter 3: The FDA Software Validation Regulations and Why You Should Validate Software Anyway\"<\/a>. <i>Medical Device Software Verification, Validation, and Compliance<\/i>. Boston, MA: Artech House. pp. 27\u201336. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" target=\"_blank\">ISBN<\/a> 9781596934238<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"https:\/\/books.google.com\/books?id=LYxH-zUSOTgC&pg=PA27\" target=\"_blank\">https:\/\/books.google.com\/books?id=LYxH-zUSOTgC&pg=PA27<\/a><\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Chapter+3%3A+The+FDA+Software+Validation+Regulations+and+Why+You+Should+Validate+Software+Anyway&rft.atitle=Medical+Device+Software+Verification%2C+Validation%2C+and+Compliance&rft.aulast=Vogel%2C+D.A.&rft.au=Vogel%2C+D.A.&rft.date=2011&rft.pages=pp.%26nbsp%3B27%E2%80%9336&rft.place=Boston%2C+MA&rft.pub=Artech+House&rft.isbn=9781596934238&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DLYxH-zUSOTgC%26pg%3DPA27&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FDAOff99-8\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FDAOff99_8-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Office of Device Evaluation, Center for Devices and Radiological Health (9 September 1999). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/MedicalDevices\/...\/ucm073779.pdf\" target=\"_blank\">\"Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices\"<\/a> (PDF). U.S. Food and Drug Administration<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.fda.gov\/downloads\/MedicalDevices\/...\/ucm073779.pdf\" target=\"_blank\">http:\/\/www.fda.gov\/downloads\/MedicalDevices\/...\/ucm073779.pdf<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 26 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Guidance+for+Industry%2C+FDA+Reviewers+and+Compliance+on+Off-The-Shelf+Software+Use+in+Medical+Devices&rft.atitle=&rft.aulast=Office+of+Device+Evaluation%2C+Center+for+Devices+and+Radiological+Health&rft.au=Office+of+Device+Evaluation%2C+Center+for+Devices+and+Radiological+Health&rft.date=9+September+1999&rft.pub=U.S.+Food+and+Drug+Administration&rft_id=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FMedicalDevices%2F...%2Fucm073779.pdf&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<li id=\"cite_note-FDAGuidance05-9\"><span class=\"mw-cite-backlink\"><a href=\"#cite_ref-FDAGuidance05_9-0\" rel=\"external_link\">\u2191<\/a><\/span> <span class=\"reference-text\"><span class=\"citation web\">Center for Devices and Radiological Health (11 May 2005). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/RegulatoryInformation\/Guidances\/ucm089543.htm\" target=\"_blank\">\"Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices\"<\/a>. U.S. Food and Drug Administration<span class=\"printonly\">. <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.fda.gov\/RegulatoryInformation\/Guidances\/ucm089543.htm\" target=\"_blank\">http:\/\/www.fda.gov\/RegulatoryInformation\/Guidances\/ucm089543.htm<\/a><\/span><span class=\"reference-accessdate\">. Retrieved 26 April 2016<\/span>.<\/span><span class=\"Z3988\" title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.btitle=Guidance+for+the+Content+of+Premarket+Submissions+for+Software+Contained+in+Medical+Devices&rft.atitle=&rft.aulast=Center+for+Devices+and+Radiological+Health&rft.au=Center+for+Devices+and+Radiological+Health&rft.date=11+May+2005&rft.pub=U.S.+Food+and+Drug+Administration&rft_id=http%3A%2F%2Fwww.fda.gov%2FRegulatoryInformation%2FGuidances%2Fucm089543.htm&rfr_id=info:sid\/en.wikipedia.org:LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\"><span style=\"display: none;\"> <\/span><\/span><\/span>\n<\/li>\n<\/ol><\/div>\n\n<!-- \nNewPP limit report\nCached time: 20190104224851\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.233 seconds\nReal time usage: 0.253 seconds\nPreprocessor visited node count: 5708\/1000000\nPreprocessor generated node count: 17097\/1000000\nPost\u2010expand include size: 45008\/2097152 bytes\nTemplate argument size: 18249\/2097152 bytes\nHighest expansion depth: 13\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 227.854 1 - -total\n100.00% 227.854 1 - Template:Reflist\n 81.74% 186.250 9 - Template:Citation\/core\n 64.08% 146.016 7 - Template:Cite_web\n 25.70% 58.548 2 - Template:Cite_book\n 5.62% 12.815 14 - Template:Citation\/make_link\n 5.26% 11.982 2 - Template:Citation\/identifier\n 1.33% 3.020 4 - Template:Hide_in_print\n 1.28% 2.912 2 - Template:Only_in_print\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8682-0!*!0!!*!*!* and timestamp 20190104224851 and revision id 25233\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software\">https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","fb5fecbcef204bee669859f6511678d4_images":[],"fb5fecbcef204bee669859f6511678d4_timestamp":1546642131,"8e821122daa731f0fa8782fae57831fa_type":"article","8e821122daa731f0fa8782fae57831fa_title":"Medical device","8e821122daa731f0fa8782fae57831fa_url":"https:\/\/www.limswiki.org\/index.php\/Medical_device","8e821122daa731f0fa8782fae57831fa_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tMedical device\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\tAny instrument, apparatus, implant, in vitro reagent, or similar or related article used for diagnostic and\/or therapeutic purposes\n A stethoscope, a popular medical device, ubiquitous in hospitals.\nA medical device is any apparatus, appliance, software, material, or other article\u2014whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and\/or therapeutic purposes and necessary for its proper application\u2014intended by the manufacturer to be used for human beings for the purpose of:\n\nDiagnosis, prevention, monitoring, treatment, or alleviation of disease;\nDiagnosis, monitoring, treatment, alleviation, or compensation for an injury or handicap;\nInvestigation, replacement, or modification of the anatomy or of a physiological process;\nControl of conception; and which does not achieve its principal intended action in or on the human body by pharmacological, immunological, or metabolic means, but which may be assisted in its function by such means\nMedical devices vary according to their intended use and indications. Examples range from simple devices such as tongue depressors, medical thermometers, and disposable gloves to advanced devices such as computers which assist in the conduct of medical testing, implants, and prostheses. Items as intricate as housings for cochlear implants are manufactured through the deep drawn and shallow drawn manufacturing processes. The design of medical devices constitutes a major segment of the field of biomedical engineering.\nThe global medical device market reached roughly $209 billion in 2006.[1]\n\nContents \n\n1 Design, prototyping, and product development \n2 Definitions \n\n2.1 European Union legal framework and definition \n2.2 Definition in United States by the Food and Drug Administration \n2.3 Definition in Canada by the Food and Drugs Act \n\n\n3 Classification \n\n3.1 Canada \n3.2 United States \n\n3.2.1 Class I: General controls \n3.2.2 Class II: General controls with special controls \n3.2.3 Class III: General controls, Special Controls and premarket approval \n\n\n3.3 European Union (EU) and European Free Trade Association (EFTA) \n3.4 Australia \n3.5 Iran \n\n\n4 Technological security issues \n5 Standardization and regulatory concerns \n\n5.1 Packaging standards \n5.2 Biocompatibility standards \n5.3 Cleanliness standards \n5.4 Mobile medical applications \n\n\n6 Academic resources \n\n6.1 University Based Research Packaging Institutes \n\n\n7 See also \n8 References \n9 External links \n\n\n Design, prototyping, and product development \nMain article: Medical device manufacturing\nMedical device manufacturing requires a level of process control according to the classification of the device. Higher risk; more controls. When in the initial R&D phase, manufacturers are now beginning to design for manufacturability. This means products can be more precision-engineered to for production to result in shorter lead times, tighter tolerances and more advanced specifications and prototypes. These days, with the aid of CAD or modelling platforms, the work is now much faster, and this can act also as a tool for strategic design generation as well as a marketing tool.[2]\nFailure to meet cost targets will lead to substantial losses for an organisation. In addition, with global competition, the R&D of new devices is not just a necessity, it is an imperative for medical device manufacturers. The realisation of a new design can be very costly, especially with the shorter product life cycle. As technology advances, there is typically a level of quality, safety and reliability that increases exponentially with time.[2]\nFor example, initial models of the artificial cardiac pacemaker were external support devices that transmits pulses of electricity to the heart muscles via electrode leads on the chest. The electrodes contact the heart directly through the chest, allowing stimulation pulses to pass through the body. Recipients of this typically suffered infection at the entrance of the electrodes, which led to the subsequent trial of the first internal pacemaker, with electrodes attached to the myocardium by thoracotomy. Future developments led to the isotope-power source that would last for the lifespan of the patient.\n\nDefinitions \nEuropean Union legal framework and definition \nBased on the New Approach, rules that relate to safety and performance of medical devices were harmonised in the EU in the 1990s. The New Approach, defined in a European Council Resolution of May 1985,[3] represents an innovative way of technical harmonisation. It aims to remove technical barriers to trade and dispel the consequent uncertainty for economic operators, to facilitate free movement of goods inside the EU.\nThe core legal framework consists of three directives: \n\nDirective 90\/385\/EEC regarding active implantable medical devices\nDirective 93\/42\/EEC regarding medical devices\nDirective 98\/79\/EC regarding in vitro diagnostic medical devices\nThey aim at ensuring a high level of protection of human health and safety and the good functioning of the Single Market. These three main directives have been supplemented over time by several modifying and implementing directives, including the last technical revision brought about by Directive 2007\/47 EC.[4]\nDirective 2007\/47\/EC defines a medical device as (paraphrasing): Any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, together with any accessories, including the software intended by its manufacturer to be used specifically for diagnostic and\/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:\n\nDiagnosis, prevention, monitoring, treatment, or alleviation of disease\nDiagnosis, monitoring, treatment, alleviation of, or compensation for an injury or handicap\nInvestigation, replacement, or modification of the anatomy or of a physiological process\nControl of conception\nThis includes devices that do not achieve their principal intended action in or on the human body by pharmacological, immunological, or metabolic means\u2014but may be assisted in their function by such means.[4]\nThe government of each Member State must appoint a competent authority responsible for medical devices. The competent authority (CA) is a body with authority to act on behalf of the member state to ensure that member state government transposes requirements of medical device directives into national law and applies them. The CA reports to the minister of health in the member state. The CA in one Member State has no jurisdiction in any other member state, but exchanges information and tries to reach common positions.\nIn the UK, for example, the Medicines and Healthcare products Regulatory Agency (MHRA) acts as a CA. In Italy it is the Ministero Salute (Ministry of Health) Medical devices must not be mistaken with medicinal products. In the EU, all medical devices must be identified with the CE mark.\nIn September 2012, the European Commission proposed new legislation aimed at enhancing safety, traceability, and transparency.[5]\n\nDefinition in United States by the Food and Drug Administration \nMedical machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory that is:\n\nRecognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them\nIntended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals\nIntended to affect the structure or any function of the body of man or other animals, and does not achieve any of its primary purpose through chemical action within or on the body of man or other animals and does not depend on metabolic action to achieve its primary purpose.[6]\nIn August 2013, the FDA released over 20 regulations aiming to improve the security of data in medical devices,[7] in response to the growing risks of limited cybersecurity.\nOn September 25, 2013 the FDA released a draft guidance document for regulation of mobile medical applications, to clarify what kind of mobile apps related to health would not be regulated, and which would be.[8][9]\n\nDefinition in Canada by the Food and Drugs Act \nThe term medical devices, as defined in the Food and Drugs Act, covers a wide range of health or medical instruments used in the treatment, mitigation, diagnosis or prevention of a disease or abnormal physical condition. Health Canada reviews medical devices to assess their safety, effectiveness, and quality before authorizing their sale in Canada.[10]\n\nClassification \nThe regulatory authorities recognize different classes of medical devices based on their design complexity, their use characteristics, and their potential for harm if misused. Each country or region defines these categories in different ways. The authorities also recognize that some devices are provided in combination with drugs, and regulation of these combination products takes this factor into consideration.\n\nCanada \nThe Medical Devices Bureau of Health Canada recognizes four classes of medical devices based on the level of control necessary to assure the safety and effectiveness of the device. Class I devices present the lowest potential risk and do not require a licence. Class II devices require the manufacturer's declaration of device safety and effectiveness, whereas Class III and IV devices present a greater potential risk and are subject to in-depth scrutiny.[10] A guidance document for device classification is published by Health Canada.[11]\nCanadian classes of medical devices correspond to the European Council Directive 93\/42\/EEC (MDD) devices:[11] \n\nClass IV (Canada) generally corresponds to Class III (ECD),\nClass III (Canada) generally corresponds to Class IIb (ECD),\nClass II (Canada) generally corresponds to Class IIa (ECD), and\nClass I (Canada) generally corresponds to Class I (ECD)\nExamples include surgical instruments (Class I), contact lenses and ultrasound scanners (Class II),\northopedic implants and hemodialysis machines (Class III), and cardiac pacemakers (Class IV).[12]\n\nUnited States \nFurther information: Federal_Food,_Drug,_and_Cosmetic_Act \u00a7 Medical_devices\nUnder the Food, Drug, and Cosmetic Act, the U.S. Food and Drug Administration recognizes three classes of medical devices, based on the level of control necessary to assure safety and effectiveness.[13] The classification procedures are described in the Code of Federal Regulations, Title 21, part 860 (usually known as 21 CFR 860).[14] The USFDA allows for two regulatory pathways that allow the marketing of medical devices. The first, and by far the most common is the so-called 510(k) process (named after the Food, Drug, and Cosmetic Act section that describes the process). A new medical device that can be demonstrated to be \"substantially equivalent\" to a previously legally marketed device can be \"cleared\" by the FDA for marketing as long as the general and special controls, as described below, are met. The vast majority of new medical devices (99%) enter the marketplace via this process. The 510(k) pathway rarely requires clinical trials. The second regulatory pathway for new medical devices is the Premarket Approval process, described below, which is similar to the pathway for a new drug approval. Typically, clinical trials are required for this premarket approval pathway.[15]\n\nClass I: General controls \nClass I devices are subject to the least regulatory control. Class I devices are subject to \"General Controls\" as are Class II and Class III devices.[13][16][17] General controls include provisions that relate to adulteration; misbranding; device registration and listing; premarket notification; banned devices; notification, including repair, replacement, or refund; records and reports; restricted devices; and good manufacturing practices.[17] Class I devices are not intended to help support or sustain life or be substantially important in preventing impairment to human health, and may not present an unreasonable risk of illness or injury.[17] Most Class I devices are exempt from the premarket notification and a few are also exempted from most good manufacturing practices regulation.[13][16][17] Examples of Class I devices include elastic bandages, examination gloves, and hand-held surgical instruments.[16]\n\nClass II: General controls with special controls \nClass II devices are those for which general controls alone cannot assure safety and effectiveness, and existing methods are available that provide such assurances.[13][16] In addition to complying with general controls, Class II devices are also subject to special controls.[16] A few Class II devices are exempt from the premarket notification.[16] Special controls may include special labeling requirements, mandatory performance standards and postmarket surveillance.[16] Devices in Class II are held to a higher level of assurance than Class I devices, and are designed to perform as indicated without causing injury or harm to patient or user. Examples of Class II devices include acupuncture needles, powered wheelchairs, infusion pumps, air purifiers, and surgical drapes.[13][16][18]\n\n Class III: General controls, Special Controls and premarket approval \nA Class III device is one for which insufficient information exists to assure safety and effectiveness solely through the general or special controls sufficient for Class I or Class II devices.[13][16] Such a device needs premarket approval, a scientific review to ensure the device's safety and effectiveness, in addition to the general controls of Class I.[13][16] Class III devices are usually those that support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential, unreasonable risk of illness or injury.[16] Examples of Class III devices that currently require a premarket notification include implantable pacemaker, pulse generators, HIV diagnostic tests, automated external defibrillators, and endosseous implants.[16]\n\n European Union (EU) and European Free Trade Association (EFTA) \nThe classification of medical devices in the European Union is outlined in Article IX of the Council Directive 93\/42\/EEC. There are basically four classes, ranging from low risk to high risk.\n\nClass I (including Is & Im)\nClass IIa\nClass IIb\nClass III\nThe authorization of medical devices is guaranteed by a Declaration of Conformity. This declaration is issued by the manufacturer itself, but for products in Class Is, Im, IIa, IIb or III, it must be verified by a Certificate of Conformity issued by a Notified Body. A Notified Body is a public or private organisation that has been accredited to validate the compliance of the device to the European Directive. Medical devices that pertain to class I (on condition they do not require sterilization or do not measure a function) can be marketed purely by self-certification.\nThe European classification depends on rules that involve the medical device's duration of body contact, invasive character, use of an energy source, effect on the central circulation or nervous system, diagnostic impact, or incorporation of a medicinal product. Certified medical devices should have the CE mark on the packaging, insert leaflets, etc.. These packagings should also show harmonised pictograms and EN standardised logos to indicate essential features such as instructions for use, expiry date, manufacturer, sterile, don't reuse, etc.\nIn November 2018 the Federal Administrative Court of Switzerland decided that the \"Sympto\" app, used to analyze a woman's menstrual cycle, was a medical device because it calculates a fertility window for each woman using personal data. The manufacturer, Sympto-Therm Foundation, argued that this was a didactic, not a medical process. the court laid down that an app is a medical device if it is to be used for any of the medical purposes provided by law, and creates or modifies health information by calculations or comparison,\nproviding information about an individual patient.[19]\n\n<\/p>\nAustralia \nThe classification of medical devices in Australia is outlined in section 41BD of the Therapeutic Goods Act 1989 and Regulation 3.2 of the Therapeutic Goods Regulations 2002, under control of the Therapeutic Goods Administration. Similarly to the EU classification, they rank in several categories, by order of increasing risk and associated required level of control. Various rules identify the device's category[20]\n\n\nMedical Devices Categories in Australia\n\n\nClassification\nLevel of Risk\n\n\nClass I\nLow\n\n\nClass I - measuring or Class I - supplied sterile or class IIa\nLow - medium\n\n\nClass IIb\nMedium - high\n\n\nClass III\nHigh\n\n\nActive implantable medical devices (AIMD)\nHigh\n\nIran \nWith the fourth world engineering rating of over a thousand medical Devices,Iran produces about 2,000 species of medical devices and medical supplies such as appliances and dental supplies and all sorts of disposable sterile medical stuff,laboratory machines and all kinds of Biomaterials and dental implants and 400 medical products are produced at the C and D risk class which all of them are licensed by the Iranian Health Ministry in terms of safety and performance based on EU standards.\nIranian medical Devices products are produced according to the European Union standards so the quality of products, skilled labour, access to the technologies of the world and the low price of products over the European countries are among the important features of these products and in these respects it is competitive with the products of European countries.\n\u200fOn cooperation with active commercial partners in the European Union, Iran exports medical devices and supplies which has Union\u2019s standards and CE Logo to the applicant countries including 40 Asian and European countries, some of which are in the rest of the world by transferring technology from Iran to other commercial partners.\nAmong the ways that Iranian producers do for exporting their products to foreign countries is exporting to foreign countries by placing products in the name of the country as that of manufacture (Made in Iran) or production of products in and packaging it in the name of the country's name and their exportation which is very welcomed by the European countries because of the contributions of other countries. It will also include the establishment of a joint production line between business partners and Iranian producing companies to manufacture and produce products to other applicants, from other production methods and export of Iranian devices and medical supplies.[21]\n\nTechnological security issues \nMedical devices such as pacemakers, insulin pumps, operating room monitors, defibrillators, and surgical instruments, including deep-brain stimulators, can incorporate the ability to transmit vital health information from a patient's body to medical professionals.[22] Some of these devices can be remotely controlled. This has engendered concern about privacy and security issues,[23] human error, and technical glitches with this technology. While only a few studies have looked at the susceptibility of medical devices to hacking, there is a risk.[24][25][26] In 2008, computer scientists proved that pacemakers and defibrillators can be hacked wirelessly via radio hardware, an antenna, and a personal computer.[27] These researchers showed they could shut down a combination heart defibrillator and pacemaker and reprogram it to deliver potentially lethal shocks or run out its battery. Jay Radcliff, a security researcher interested in the security of medical devices, raised fears about the safety of these devices. He shared his concerns at the Black Hat security conference.[28] Radcliff fears that the devices are vulnerable and has found that a lethal attack is possible against those with insulin pumps and glucose monitors. Some medical device makers downplay the threat from such attacks and argue that the demonstrated attacks have been performed by skilled security researchers and are unlikely to occur in the real world. At the same time, other makers have asked software security experts to investigate the safety of their devices.[29] As recently as June 2011, security experts showed that by using readily available hardware and a user manual, a scientist could both tap into the information on the system of a wireless insulin pump in combination with a glucose monitor. With the PIN of the device, the scientist could wirelessly control the dosage of the insulin.[30] Anand Raghunathan, a researcher in this study, explains that medical devices are getting smaller and lighter so that they can be easily worn. The downside is that additional security features would put an extra strain on the battery and size and drive up prices. Dr. William Maisel offered some thoughts on the motivation to engage in this activity. Motivation to do this hacking might include acquisition of private information for financial gain or competitive advantage; damage to a device manufacturer's reputation; sabotage; intent to inflict financial or personal injury or just satisfaction for the attacker.[31] Researchers suggest a few safeguards. One would be to use rolling codes. Another solution is to use a technology called \"body-coupled communication\" that uses the human skin as a wave guide for wireless communication. On 28 December 2016 the US Food and Drug Administration released its recommendations that are not legally enforceable for how medical device manufacturers should maintain the security of Internet-connected devices.[32][33]\n\nStandardization and regulatory concerns \nThe ISO standards for medical devices are covered by ICS 11.100.20 and 11.040.01.[34][35] The quality and risk management regarding the topic for regulatory purposes is convened by ISO 13485 and ISO 14971. ISO 13485:2003 is applicable to all providers and manufacturers of medical devices, components, contract services and distributors of medical devices. The standard is the basis for regulatory compliance in local markets, and most export markets.[36][37][38] Additionally, ISO 9001:2008 sets precedence because it signifies that a company engages in the creation of new products. It requires that the development of manufactured products have an approval process and a set of rigorous quality standards and development records before the product is distributed.[39] Further standards are IEC 60601-1 which is for electrical devices (mains-powered as well as battery powered), EN 45502-1 which is for Active implantable medical devices, and IEC 62304 for medical software. The US FDA also published a series of guidances for industry regarding this topic against 21 CFR 820 Subchapter H\u2014Medical Devices.[40] Subpart B includes quality system requirements, an important component of which are design controls (21 CFR 820.30). To meet the demands of these industry regulation standards, a growing number of medical device distributors are putting the complaint management process at the forefront of their quality management practices. This approach further mitigates risks and increases visibility of quality issues.[41]\nStarting in the late 1980s[42] the FDA increased its involvement in reviewing the development of medical device software. The precipitant for change was a radiation therapy device (Therac-25) that overdosed patients because of software coding errors.[43] FDA is now focused on regulatory oversight on medical device software development process and system-level testing.[44]\nA 2011 study by Dr. Diana Zuckerman and Paul Brown of the National Research Center for Women and Families, and Dr. Steven Nissen of the Cleveland Clinic, published in the Archives of Internal Medicine, showed that most medical devices recalled in the last five years for \"serious health problems or death\" had been previously approved by the FDA using the less stringent, and cheaper, 510(k) process. In a few cases the devices had been deemed so low-risk that they did not need FDA regulation. Of the 113 devices recalled, 35 were for cardiovascular issues.[15] This may lead to a reevaluation of FDA procedures and better oversight.\n \nIn 2014-2015 a new international agreement, the Medical Device Single Audit Program (MDSAP), was put in place with five participant countries: Australia, Brazil, Canada, Japan, and the United States. The aim of this program was to \"develop a process that allows a single audit, or inspection to ensure the medical device regulatory requirements for all five countries are satisfied\".[45]\n\n<\/p>In 2018, an investigation involving journalists across 36 countries coordinated by the International Consortium of Investigative Journalists (ICIJ) prompted calls for reform in the United States, particularly around the 510(k) substantial equivalence process;[46] the investigation prompted similar calls in the UK and Europe Union.[47]\n\nPackaging standards \nMedical device packaging is highly regulated. Often medical devices and products are sterilized in the package.[48]\nSterility must be maintained throughout distribution to allow immediate use by physicians. A series of special packaging tests measure the ability of the package to maintain sterility. Relevant standards include:\n\nASTM D1585 \u2013 Guide for Integrity Testing of Porous Medical Packages\nASTM F2097 \u2013 Standard Guide for Design and Evaluation of Primary Flexible Packaging for Medical Products\nASTM F3475-11 \u2013 Standard Guide for Biocompatibility Evaluation of Medical Device Packaging Materials[49]\nEN 868 Packaging materials and systems for medical devices to be sterilized, General requirements and test methods\nISO 11607 Packaging for terminally sterilized medical devices\nPackage testing documents and ensures that packages meet regulations and end-use requirements. Manufacturing processes must be controlled and validated to ensure consistent performance.[50][51]\n\nBiocompatibility standards \nISO 10993 - Biological Evaluation of Medical Devices\nCleanliness standards \nMedical device cleanliness has come under greater scrutiny since 2000, when Sulzer Orthopedics recalled several thousand metal hip implants that contained a manufacturing residue.[52] Based on this event, ASTM established a new task group (F04.15.17) for established test methods, guidance documents, and other standards to address cleanliness of medical devices. This task group has issued two standards for permanent implants to date: 1. ASTM F2459: Standard test method for extracting residue from metallic medical components and quantifying via gravimetric analysis[53] 2. ASTM F2847: Standard Practice for Reporting and Assessment of Residues on Single Use Implants[54] 3. ASTM F3172: Standard Guide for Validating Cleaning Processes Used During the Manufacture of Medical Devices [55]\nIn addition, the cleanliness of re-usable devices has led to a series of standards, including:\n\nASTM E2314: Standard Test Method for Determination of Effectiveness of Cleaning Processes for Reusable Medical Instruments Using a Microbiologic Method (Simulated Use Test)\"[56]\nASTM D7225: Standard Guide for Blood Cleaning Efficiency of Detergents and Washer-Disinfectors[57]\nASTM F3208: Standard Guide for Selecting Test Soils for Validation of Cleaning Methods for Reusable Medical Devices[55]\nThe ASTM F04.15.17 task group is working on several new standards that involve designing implants for cleaning, selection and testing of brushes for cleaning reusable devices, and cleaning assessment of medical devices made by additive manufacturing.[58] Additionally, the FDA is establishing new guidelines for reprocessing reusable medical devices, such as orthoscopic shavers, endoscopes, and suction tubes.[59]\n\nMobile medical applications \nWith the rise of smartphone usage in the medical space, in 2013, the FDA issued to regulate mobile medical applications and protect users from their unintended use, soon followed by European and other regulatory agencies. This guidance distinguishes the apps subjected to regulation based on the marketing claims of the apps.[60] Incorporation of the guidelines during the development phase of such apps can be considered as developing a medical device; the regulations have to adapt and propositions for expedite approval may be required due to the nature of 'versions' of mobile application development.[61][62]\n\nAcademic resources \nMedical & Biological Engineering & Computing\nExpert Review of Medical Devices\nJournal of Clinical Engineering[63]\nUniversity Based Research Packaging Institutes \nUniversity of Minnesota - Medical Devices Center (MDC)\nUniversity of Strathclyde - Strathclyde Institute of Medical Devices (SIMD)\nFlinders University - Medical Device Research Institute (MDRI)\nMichigan State University - School of Packaging (SoP)[64]\nSee also \n\n Biomedical engineering – Application of engineering principles and design concepts to medicine and biology for healthcare purposes\n Biomedical equipment technician\n Clinical engineering\n Design history file\n Durable medical equipment\n Electromagnetic compatibility\n Electronic health record\n Federal Institute for Drugs and Medical Devices\n In vitro diagnostics\n GHTF\n Health Level 7\n Home medical equipment\n Implant (medicine)\n ISO 13485\n List of common EMC test standards\n Medical Devices Directive\n Medical device hijack\n Medical equipment – Equipment designed to aid in the diagnosis, monitoring or treatment of medical conditions\n Medical logistics\n Medical software\n Safety engineering\nSection 201(h) of Federal Food, Drug, and Cosmetic Act\n Telemedicine – Medical care by telecommunication\n\nReferences \n\n\n^ \"Market Report: World Medical Devices Market\". Acmite Market Intelligence. 2014. Retrieved 15 June 2014 . \n\n^ a b Wong, K., Tu, J., Sun, Z., and Dissanayake, D. W. \"Methods in Research and Development of Biomedical Devices\". World Scientific Publishing. Retrieved 29 May 2013 . CS1 maint: Multiple names: authors list (link) \n\n^ \"Eur-lex Europa\". 2005. Retrieved 15 June 2014 . \n\n^ a b \"Directive 2007\/47\/ec of the European parliament and of the council\". Eur-lex Europa. 5 September 2007. Retrieved 15 June 2014 . \n\n^ \"Revision of the medical device directives\". European Commission. 2013. Retrieved 15 June 2014 . \n\n^ US Food and Drug Administration,\n\"Is The Product A Medical Device?\" \n\n^ \"Federal Register Vol 78, No 151, page 47712\" (PDF) . U.S. Government Publishing Office. 6 August 2013. Retrieved 17 February 2016 . \n\n^ FDA Mobile Medical Applications: Guidance for Industry and Food and Drug Administration Staff \n\n^ Piccardo, Carmelita (28 July 2014). \"FDA Eases the Way for New Product Development\". NPI Services, Inc. Retrieved 17 February 2016 . \n\n^ a b \"Medical Devices Regulations SOR\/98-282\" (PDF) . Department of Justice Canada. 16 December 2011. Retrieved 25 August 2014 . \n\n^ a b \"Guidance Document - Guidance on the Risk-based Classification System for Non-In Vitro Diagnostic Devices (non-IVDDs)\". Health Canada. 2015-04-23. Retrieved 2016-04-21 . \n\n^ \"Medical Device Regulation In Canada: A Primer\" (PDF) . Health Technology Update. No. 5. Ottawa: Canadian Agency for Drugs and Technologies in Health. 2007-01-12. pp. 2\u20133. Retrieved 2016-04-21 . \n\n^ a b c d e f g \"Device Classification\". Medical Devices. U.S. Food and Drug Administration. Retrieved 2010-10-15 . \n\n^ \"Title 21\u2014Food and drugs: Chapter i\u2014Food and drug administration: Department of health and human services: Subchapter H\u2014Medical devices: Part 860 Medical device classification procedures\". CFR \u2013 Code of Federal Regulations Title 21. U.S. Food and Drug Administration. Retrieved 15 Oct 2010 . \n\n^ a b Zuckerman, Diana (2011), \"Medical Device Recalls and the FDA Approval Process\", Archives of Internal Medicine, 171 (11): 1006\u201311, doi:10.1001\/archinternmed.2011.30, PMID 21321283 \n\n^ a b c d e f g h i j k l \"General and Special Controls\". Medical Devices. U.S. Food and Drug Administration. Retrieved 2010-10-15 . \n\n^ a b c d \"General Controls for Medical Devices\". Medical Devices. U.S. Food and Drug Administration. Retrieved 2010-10-15 . \n\n^ \"Frequently Asked Questions about Acupuncture\". American College of Acupuncture & Oriental Medicine. Archived from the original on 2014-03-18. \n\n^ \"BVGer-Urteil zur rechtlichen Qualifikation von Gesundheitsapps: Die App \"Sympto\" ist ein Medizinprodukt\". Lexology. 6 November 2018. Retrieved 13 December 2018 . \n\n^ TGA, Australian regulatory guidelines for medical devices (ARGMD) Version 1.1, May 2011, http:\/\/www.tga.gov.au\/pdf\/devices-argmd-01.pdf \n\n^ \"Iran's Medical Devices at a glance\". IMED.ir. Retrieved 2018-11-10 . \n\n^ Jordan Robertson. Associated Press 8\/4\/2011 \n\n^ Altawy, R; Youssef, A. \"Security Trade-offs in Cyber Physical Systems: A Case Study Survey on Implantable Medical Devices\". IEEE Access. \n\n^ New Health Hazard:Hackable Medical Implants. MSNBC.com's Technology \n\n^ Camara, Carmen; Peris-Lopez, Pedro; Tapiador, Juan E. (2015-06-01). \"Security and privacy issues in implantable medical devices: A comprehensive survey\". Journal of Biomedical Informatics. 55: 272\u2013289. doi:10.1016\/j.jbi.2015.04.007. ISSN 1532-0480. PMID 25917056. \n\n^ Pycroft, Laurie; Boccard, Sandra G.; Owen, Sarah L. F.; Stein, John F.; Fitzgerald, James J.; Green, Alexander L.; Aziz, Tipu Z. (2016-05-13). \"Brainjacking: implant security issues in invasive neuromodulation\". World Neurosurgery. 92: 454\u2013462. doi:10.1016\/j.wneu.2016.05.010. ISSN 1878-8769. PMID 27184896. \n\n^ Takahashi, Dean (8 Aug 2008). \"Excuse Me While I turn off Your Pacemaker\". Venture Beat. \n\n^ Hacking Medical Devices for Fun and Insulin: Breaking the Human SCADA System \n\n^ Globe and Mail. Thursday Oct. 27, 2011 Jim Finkle. Insulin Pumps Vulnerable to Attacks by Hackers \n\n^ Daily Tech June 15, 2011 Nidhi Subbaraman \n\n^ Daily Tech June 15, 2011 Nidhi SubbaramanDaily Tech \n\n^ Becker, Rachel (27 December 2016). \"New cybersecurity guidelines for medical devices tackle evolving threats\". The Verge. Retrieved 29 December 2016 . \n\n^ \"Postmarket Management of Cybersecurity in Medical Devices\" (PDF) . 28 December 2016. Retrieved 29 December 2016 . \n\n^ International Organization for Standardization. \"11.100.20: Biological evaluation of medical devices\". Retrieved 10 April 2009 . \n\n^ International Organization for Standardization. \"11.040: Medical equipment\". Retrieved 26 April 2009 . \n\n^ \"ISO 13485:2003 - Medical devices -- Quality management systems -- Requirements for regulatory purposes\". www.iso.org. Retrieved 27 March 2018 . \n\n^ Canada, Health. \"Quality Systems ISO 13485 - Canada.ca\". www.hc-sc.gc.ca. Retrieved 27 March 2018 . \n\n^ \"ISO 13485 in USA\" (PDF) . fda.gov. Retrieved 27 March 2018 . \n\n^ \"ISO Standards Applied to Medical Device Manufacturing\" (PDF) . MK Precision. Retrieved 27 October 2014 . \n\n^ Food and Drug Administration Standards (Medical Devices) Page Last Updated: 11 March 2014. Accessed 18 May 2014 \n\n^ \"Preparing a Complaints\/eMDR System for Upcoming FDA Mandate\". Sparta Systems. 18 May 2015. \n\n^ \"Therac-25 Timeline\". Computingcases.org. Retrieved 2011-01-04 . \n\n^ Jones, Paul; Jetley, Raoul; Abraham, Jay (2010-02-09). \"A Formal Methods-based verification approach to medical device software analysis\". Embedded Systems Design. Retrieved 2016-04-21 . \n\n^ FDA (2010-09-08). \"Infusion Pump Software Safety Research at FDA\". FDA. Retrieved 2010-09-09 . \n\n^ Trautman, Kim (16 January 2015). \"Australia, Brazil, Canada, Japan, and the US: Safeguarding Medical Devices\". FDA Voice. Food and Drug Administration. \n\n^ Lenzer, Jeanne (2018-11-27). \"FDA recommends \"modernizing\" review of devices in wake of global investigation\". BMJ. 363: k5026. doi:10.1136\/bmj.k5026. ISSN 1756-1833. PMID 30482750. \n\n^ Coombes, Rebecca (2018-11-26). \"Surgeons call for compulsory registers of all new medical devices\". BMJ. 363: k5010. doi:10.1136\/bmj.k5010. ISSN 1756-1833. PMID 30478186. \n\n^ Dacy, D (2010), \"Optimizing Package Design for EtO Sterilization\", Medical Device and Diagnostic Industry, 33 (1) \n\n^ \"ASTM International - Standards Worldwide\". www.astm.org. Retrieved 2017-08-23 . \n\n^ \nBix, L.; Fuente, J. (2009), \"Medical Device Packaging\", in Yam, K. L, Wiley Encyclopedia of Packaging Technology, Wiley, ISBN 978-0-470-08704-6 \n\n^ \nFotis, N.; Bix, L. (2006), \"Sample Size Selection Using Margin of Error Approach\", Medical Device and Diagnostic Industry, 28 (10): 80\u201389 \n\n^ \"Spiegelberg, S.H., Deluzio, K.J., Muratoglu, O.K., \"Extractable residue from recalled Inter-Op acetabular shells,\" 49th Annual Meeting of the Orthopaedic Research Society, 2003\" (PDF) . ors.org. Retrieved 27 March 2018 . \n\n^ \"Standard Test Method for Extracting Residue from Metallic Medical Components and Quantifying via Gravimetric Analysis\". ASTM International Products and Services. Retrieved 15 June 2014 . \n\n^ \"Standard Practice for Reporting and Assessment of Residues on Single Use Implants\". ASTM Products and Services. Retrieved 15 June 2014 . \n\n^ a b \"ASTM F3208 - 17 Standard Guide for Selecting Test Soils for Validation of Cleaning Methods for Reusable Medical Devices\". www.astm.org. Retrieved 27 March 2018 . \n\n^ \"Standard Test Method for Determination of Effectiveness of Cleaning Processes for Reusable Medical Instruments Using a Microbiologic Method (Simulated Use Test)\". ASTM International - Products and Services. Retrieved 15 June 2014 . \n\n^ \"Standard Guide for Blood Cleaning Efficiency of Detergents and Washer-Disinfectors\". 2014. Retrieved 15 June 2014 . \n\n^ \"Committee F04 on Medical and Surgical Materials and Devices\". 2014. Retrieved 15 June 2014 . \n\n^ \"Reprocessing of Reusable Medical Devices\". U.S. Department of Health and Human Services - Food and Drug Administration - Medical Devices. 2014. Retrieved 15 June 2014 . \n\n^ http:\/\/www.fda.gov\/MedicalDevices\/ProductsandMedicalProcedures\/ConnectedHealth\/MobileMedicalApplications\/ucm255978.htm \n\n^ Yetisen A. K.; Martinez-Hurtado J. L.; et al. (2014). \"The regulation of mobile medical applications\". Lab on a Chip. 14 (5): 833\u2013840. doi:10.1039\/C3LC51235E. \n\n^ Vincent, Christopher James; Niezen, Gerrit; O'Kane, Aisling Ann; Stawarz, Katarzyna (3 June 2015). \"Can Standards and Regulations Keep Up With Health Technology?\". JMIR mHealth and uHealth. 3 (2): e64. doi:10.2196\/mhealth.3918. \n\n^ Lippincott Williams & Wilkins. \"Journal Information\". Retrieved 10 April 2009 . \n\n^ \"School of Packaging\". School of Packaging. Retrieved 2017-08-23 . \n\n\nExternal links \nUS Food and Drug Administration \u2013 Center for Devices and Radiological Health\nPremarket Notification (510k)\nPremarket Approval (PMA)\nFDA \u2013 Is the Product a Medical Device?\nMHRA - Medical devices regulation and safety\nEC - Medical devices\nHealth Canada - List of Recognized Standards for Medical Devices (International)\nISO - Standards catalogue: 11.040.01: Medical equipment in general\nRadio Frequency Wireless Technology in Medical Devices - Guidance for Industry and Food and Drug Administration Staff. FDA (2013)\n\n\n\n<\/pre>\n\nNotes \nThis article is a direct transclusion of the Wikipedia article and therefore may not meet the same editing standards as LIMSwiki.\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/Medical_device\">https:\/\/www.limswiki.org\/index.php\/Medical_device<\/a>\n\t\t\t\t\tCategories: Implants (medicine)Medical devicesHidden category: Articles transcluded from other wikis\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tPage\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 22 February 2016, at 21:21.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 2,554 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","8e821122daa731f0fa8782fae57831fa_html":"<body class=\"mediawiki ltr sitedir-ltr ns-0 ns-subject page-Medical_device skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">Medical device<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div class=\"mw-parser-output\"><div class=\"shortdescription nomobile noexcerpt noprint searchaux\" style=\"display:none\">Any instrument, apparatus, implant, in vitro reagent, or similar or related article used for diagnostic and\/or therapeutic purposes<\/div>\n<div class=\"thumb tright\"><div class=\"thumbinner\" style=\"width:222px;\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/File:Stetoskop.jpg\" class=\"image\" rel=\"external_link\" target=\"_blank\"><img alt=\"\" src=\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/b\/bf\/Stetoskop.jpg\/220px-Stetoskop.jpg\" width=\"220\" height=\"235\" class=\"thumbimage\" \/><\/a> <div class=\"thumbcaption\"><div class=\"magnify\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/File:Stetoskop.jpg\" class=\"internal\" title=\"Enlarge\" rel=\"external_link\" target=\"_blank\"><\/a><\/div>A <a href=\"https:\/\/en.wikipedia.org\/wiki\/Stethoscope\" title=\"Stethoscope\" rel=\"external_link\" target=\"_blank\">stethoscope<\/a>, a popular medical device, ubiquitous in hospitals.<\/div><\/div><\/div>\n<p>A <b>medical device<\/b> is any apparatus, appliance, software, material, or other article\u2014whether used alone or in combination, including the software intended by its manufacturer to be used specifically for diagnostic and\/or therapeutic purposes and necessary for its proper application\u2014intended by the manufacturer to be used for human beings for the purpose of:\n<\/p>\n<ul><li>Diagnosis, prevention, monitoring, treatment, or alleviation of disease;<\/li>\n<li>Diagnosis, monitoring, treatment, alleviation, or compensation for an injury or handicap;<\/li>\n<li>Investigation, replacement, or modification of the anatomy or of a physiological process;<\/li>\n<li>Control of conception; and which does not achieve its principal intended action in or on the human body by pharmacological, immunological, or metabolic means, but which may be assisted in its function by such means<\/li><\/ul>\n<p>Medical devices vary according to their intended use and indications. Examples range from simple devices such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Tongue_depressor\" title=\"Tongue depressor\" rel=\"external_link\" target=\"_blank\">tongue depressors<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_thermometer\" title=\"Medical thermometer\" rel=\"external_link\" target=\"_blank\">medical thermometers<\/a>, and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_glove\" title=\"Medical glove\" rel=\"external_link\" target=\"_blank\">disposable gloves<\/a> to advanced devices such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Computer\" title=\"Computer\" rel=\"external_link\" target=\"_blank\">computers<\/a> which assist in the conduct of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_test\" title=\"Medical test\" rel=\"external_link\" target=\"_blank\">medical testing<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Implant_(medicine)\" title=\"Implant (medicine)\" rel=\"external_link\" target=\"_blank\">implants<\/a>, and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Prosthesis\" title=\"Prosthesis\" rel=\"external_link\" target=\"_blank\">prostheses<\/a>. Items as intricate as housings for cochlear implants are manufactured through the deep drawn and shallow drawn manufacturing processes. The design of medical devices constitutes a major segment of the field of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Biomedical_engineering\" title=\"Biomedical engineering\" rel=\"external_link\" target=\"_blank\">biomedical engineering<\/a>.\n<\/p><p>The global medical device market reached roughly $209 billion in 2006.<sup id=\"rdp-ebb-cite_ref-1\" class=\"reference\"><a href=\"#cite_note-1\" rel=\"external_link\">[1]<\/a><\/sup>\n<\/p>\n\n<h2><span id=\"rdp-ebb-Design.2C_prototyping.2C_and_product_development\"><\/span><span class=\"mw-headline\" id=\"Design,_prototyping,_and_product_development\">Design, prototyping, and product development<\/span><\/h2>\n<div role=\"note\" class=\"hatnote navigation-not-searchable\">Main article: <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_device_manufacturing\" title=\"Medical device manufacturing\" rel=\"external_link\" target=\"_blank\">Medical device manufacturing<\/a><\/div>\n<p>Medical device manufacturing requires a level of process control according to the classification of the device. Higher risk; more controls. When in the initial R&D phase, manufacturers are now beginning to design for manufacturability. This means products can be more precision-engineered to for production to result in shorter lead times, tighter tolerances and more advanced specifications and prototypes. These days, with the aid of CAD or modelling platforms, the work is now much faster, and this can act also as a tool for strategic design generation as well as a marketing tool.<sup id=\"rdp-ebb-cite_ref-bemd_2-0\" class=\"reference\"><a href=\"#cite_note-bemd-2\" rel=\"external_link\">[2]<\/a><\/sup>\n<\/p><p>Failure to meet cost targets will lead to substantial losses for an organisation. In addition, with global competition, the R&D of new devices is not just a necessity, it is an imperative for medical device manufacturers. The realisation of a new design can be very costly, especially with the shorter product life cycle. As technology advances, there is typically a level of quality, safety and reliability that increases exponentially with time.<sup id=\"rdp-ebb-cite_ref-bemd_2-1\" class=\"reference\"><a href=\"#cite_note-bemd-2\" rel=\"external_link\">[2]<\/a><\/sup>\n<\/p><p>For example, initial models of the artificial cardiac pacemaker were external support devices that transmits pulses of electricity to the heart muscles via electrode leads on the chest. The electrodes contact the heart directly through the chest, allowing stimulation pulses to pass through the body. Recipients of this typically suffered infection at the entrance of the electrodes, which led to the subsequent trial of the first internal pacemaker, with electrodes attached to the myocardium by thoracotomy. Future developments led to the isotope-power source that would last for the lifespan of the patient.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Definitions\">Definitions<\/span><\/h2>\n<h3><span class=\"mw-headline\" id=\"European_Union_legal_framework_and_definition\">European Union legal framework and definition<\/span><\/h3>\n<p>Based on the <i>New Approach<\/i>, rules that relate to safety and performance of medical devices were harmonised in the EU in the 1990s. The <i>New Approach<\/i>, defined in a European Council Resolution of May 1985,<sup id=\"rdp-ebb-cite_ref-3\" class=\"reference\"><a href=\"#cite_note-3\" rel=\"external_link\">[3]<\/a><\/sup> represents an innovative way of technical harmonisation. It aims to remove technical barriers to trade and dispel the consequent uncertainty for economic operators, to facilitate free movement of goods inside the EU.\n<\/p><p>The core legal framework consists of three directives: \n<\/p>\n<ul><li>Directive 90\/385\/EEC regarding active implantable medical devices<\/li>\n<li>Directive 93\/42\/EEC regarding medical devices<\/li>\n<li>Directive 98\/79\/EC regarding <i>in vitro<\/i> diagnostic medical devices<\/li><\/ul>\n<p>They aim at ensuring a high level of protection of human health and safety and the good functioning of the Single Market. These three main directives have been supplemented over time by several modifying and implementing directives, including the last technical revision brought about by Directive 2007\/47 EC.<sup id=\"rdp-ebb-cite_ref-:0_4-0\" class=\"reference\"><a href=\"#cite_note-:0-4\" rel=\"external_link\">[4]<\/a><\/sup>\n<\/p><p>Directive 2007\/47\/EC defines a medical device as (paraphrasing): Any instrument, apparatus, appliance, software, material or other article, whether used alone or in combination, together with any accessories, including the software intended by its manufacturer to be used specifically for diagnostic and\/or therapeutic purposes and necessary for its proper application, intended by the manufacturer to be used for human beings for the purpose of:\n<\/p>\n<ul><li>Diagnosis, prevention, monitoring, treatment, or alleviation of disease<\/li>\n<li>Diagnosis, monitoring, treatment, alleviation of, or compensation for an injury or handicap<\/li>\n<li>Investigation, replacement, or modification of the anatomy or of a physiological process<\/li>\n<li>Control of conception<\/li><\/ul>\n<p>This includes devices that do not achieve their principal intended action in or on the human body by pharmacological, immunological, or metabolic means\u2014but may be assisted in their function by such means.<sup id=\"rdp-ebb-cite_ref-:0_4-1\" class=\"reference\"><a href=\"#cite_note-:0-4\" rel=\"external_link\">[4]<\/a><\/sup>\n<\/p><p>The government of each Member State must appoint a <i>competent authority<\/i> responsible for medical devices. The <a href=\"https:\/\/en.wikipedia.org\/wiki\/Competent_authority\" title=\"Competent authority\" rel=\"external_link\" target=\"_blank\">competent authority<\/a> (CA) is a body with authority to act on behalf of the member state to ensure that member state government transposes requirements of medical device directives into national law and applies them. The CA reports to the minister of health in the member state. The CA in one Member State has no jurisdiction in any other member state, but exchanges information and tries to reach common positions.\n<\/p><p>In the UK, for example, the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medicines_and_Healthcare_products_Regulatory_Agency\" title=\"Medicines and Healthcare products Regulatory Agency\" rel=\"external_link\" target=\"_blank\">Medicines and Healthcare products Regulatory Agency<\/a> (MHRA) acts as a CA. In Italy it is the Ministero Salute (Ministry of Health) Medical devices must not be mistaken with <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medicinal_product\" class=\"mw-redirect\" title=\"Medicinal product\" rel=\"external_link\" target=\"_blank\">medicinal products<\/a>. In the EU, all medical devices must be identified with the <a href=\"https:\/\/en.wikipedia.org\/wiki\/CE_mark\" class=\"mw-redirect\" title=\"CE mark\" rel=\"external_link\" target=\"_blank\">CE mark<\/a>.\n<\/p><p>In September 2012, the European Commission proposed new legislation aimed at enhancing safety, traceability, and transparency.<sup id=\"rdp-ebb-cite_ref-5\" class=\"reference\"><a href=\"#cite_note-5\" rel=\"external_link\">[5]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Definition_in_United_States_by_the_Food_and_Drug_Administration\">Definition in United States by the Food and Drug Administration<\/span><\/h3>\n<p>Medical machine, contrivance, implant, <i>in vitro<\/i> reagent, or other similar or related article, including a component part, or accessory that is:\n<\/p>\n<ul><li>Recognized in the official <a href=\"https:\/\/en.wikipedia.org\/wiki\/National_Formulary\" class=\"mw-redirect\" title=\"National Formulary\" rel=\"external_link\" target=\"_blank\">National Formulary<\/a>, or the <a href=\"https:\/\/en.wikipedia.org\/wiki\/United_States_Pharmacopoeia\" class=\"mw-redirect\" title=\"United States Pharmacopoeia\" rel=\"external_link\" target=\"_blank\">United States Pharmacopoeia<\/a>, or any supplement to them<\/li>\n<li>Intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals<\/li>\n<li>Intended to affect the structure or any function of the body of man or other animals, and does not achieve any of its primary purpose through chemical action within or on the body of man or other animals and does not depend on metabolic action to achieve its primary purpose.<sup id=\"rdp-ebb-cite_ref-6\" class=\"reference\"><a href=\"#cite_note-6\" rel=\"external_link\">[6]<\/a><\/sup><\/li><\/ul>\n<p>In August 2013, the FDA released over 20 regulations aiming to improve the security of data in medical devices,<sup id=\"rdp-ebb-cite_ref-7\" class=\"reference\"><a href=\"#cite_note-7\" rel=\"external_link\">[7]<\/a><\/sup> in response to the growing risks of limited <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cybersecurity\" class=\"mw-redirect\" title=\"Cybersecurity\" rel=\"external_link\" target=\"_blank\">cybersecurity<\/a>.\n<\/p><p>On September 25, 2013 the FDA released a draft guidance document for regulation of mobile medical applications, to clarify what kind of mobile apps related to health would not be regulated, and which would be.<sup id=\"rdp-ebb-cite_ref-8\" class=\"reference\"><a href=\"#cite_note-8\" rel=\"external_link\">[8]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-9\" class=\"reference\"><a href=\"#cite_note-9\" rel=\"external_link\">[9]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Definition_in_Canada_by_the_Food_and_Drugs_Act\">Definition in Canada by the Food and Drugs Act<\/span><\/h3>\n<p>The term medical devices, as defined in the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Food_and_Drugs_Act\" title=\"Food and Drugs Act\" rel=\"external_link\" target=\"_blank\">Food and Drugs Act<\/a>, covers a wide range of health or medical instruments used in the treatment, mitigation, diagnosis or prevention of a disease or abnormal physical condition. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Health_Canada\" title=\"Health Canada\" rel=\"external_link\" target=\"_blank\">Health Canada<\/a> reviews medical devices to assess their safety, effectiveness, and quality before authorizing their sale in Canada.<sup id=\"rdp-ebb-cite_ref-Canada_regulations_10-0\" class=\"reference\"><a href=\"#cite_note-Canada_regulations-10\" rel=\"external_link\">[10]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Classification\">Classification<\/span><\/h2>\n<p>The regulatory authorities recognize different classes of medical devices based on their design complexity, their use characteristics, and their potential for harm if misused. Each country or region defines these categories in different ways. The authorities also recognize that some devices are provided in combination with drugs, and regulation of these combination products takes this factor into consideration.\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Canada\">Canada<\/span><\/h3>\n<p>The Medical Devices Bureau of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Health_Canada\" title=\"Health Canada\" rel=\"external_link\" target=\"_blank\">Health Canada<\/a> recognizes four classes of medical devices based on the level of control necessary to assure the safety and effectiveness of the device. Class I devices present the lowest potential risk and do not require a licence. Class II devices require the manufacturer's declaration of device safety and effectiveness, whereas Class III and IV devices present a greater potential risk and are subject to in-depth scrutiny.<sup id=\"rdp-ebb-cite_ref-Canada_regulations_10-1\" class=\"reference\"><a href=\"#cite_note-Canada_regulations-10\" rel=\"external_link\">[10]<\/a><\/sup> A guidance document for device classification is published by Health Canada.<sup id=\"rdp-ebb-cite_ref-HealthCanada_11-0\" class=\"reference\"><a href=\"#cite_note-HealthCanada-11\" rel=\"external_link\">[11]<\/a><\/sup>\n<\/p><p>Canadian classes of medical devices correspond to the European Council Directive 93\/42\/EEC (MDD) devices:<sup id=\"rdp-ebb-cite_ref-HealthCanada_11-1\" class=\"reference\"><a href=\"#cite_note-HealthCanada-11\" rel=\"external_link\">[11]<\/a><\/sup> \n<\/p>\n<ul><li>Class IV (Canada) generally corresponds to Class III (ECD),<\/li>\n<li>Class III (Canada) generally corresponds to Class IIb (ECD),<\/li>\n<li>Class II (Canada) generally corresponds to Class IIa (ECD), and<\/li>\n<li>Class I (Canada) generally corresponds to Class I (ECD)<\/li><\/ul>\n<p>Examples include surgical instruments (Class I), contact lenses and ultrasound scanners (Class II),\northopedic implants and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Hemodialysis\" title=\"Hemodialysis\" rel=\"external_link\" target=\"_blank\">hemodialysis<\/a> machines (Class III), and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cardiac_pacemaker\" title=\"Cardiac pacemaker\" rel=\"external_link\" target=\"_blank\">cardiac pacemakers<\/a> (Class IV).<sup id=\"rdp-ebb-cite_ref-12\" class=\"reference\"><a href=\"#cite_note-12\" rel=\"external_link\">[12]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"United_States\">United States<\/span><\/h3>\n<div role=\"note\" class=\"hatnote navigation-not-searchable\">Further information: <a href=\"https:\/\/en.wikipedia.org\/wiki\/Federal_Food,_Drug,_and_Cosmetic_Act#Medical_devices\" title=\"Federal Food, Drug, and Cosmetic Act\" rel=\"external_link\" target=\"_blank\">Federal_Food,_Drug,_and_Cosmetic_Act \u00a7 Medical_devices<\/a><\/div>\n<p>Under the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Federal_Food,_Drug,_and_Cosmetic_Act#Medical_devices\" title=\"Federal Food, Drug, and Cosmetic Act\" rel=\"external_link\" target=\"_blank\">Food, Drug, and Cosmetic Act<\/a>, the U.S. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Food_and_Drug_Administration\" title=\"Food and Drug Administration\" rel=\"external_link\" target=\"_blank\">Food and Drug Administration<\/a> recognizes three classes of medical devices, based on the level of control necessary to assure safety and effectiveness.<sup id=\"rdp-ebb-cite_ref-classification_13-0\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup> The classification procedures are described in the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Code_of_Federal_Regulations\" title=\"Code of Federal Regulations\" rel=\"external_link\" target=\"_blank\">Code of Federal Regulations<\/a>, Title 21, part 860 (usually known as 21 CFR 860).<sup id=\"rdp-ebb-cite_ref-14\" class=\"reference\"><a href=\"#cite_note-14\" rel=\"external_link\">[14]<\/a><\/sup> The USFDA allows for two regulatory pathways that allow the marketing of medical devices. The first, and by far the most common is the so-called 510(k) process (named after the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Federal_Food,_Drug,_and_Cosmetic_Act#Medical_devices\" title=\"Federal Food, Drug, and Cosmetic Act\" rel=\"external_link\" target=\"_blank\">Food, Drug, and Cosmetic Act<\/a> section that describes the process). A new medical device that can be demonstrated to be \"substantially equivalent\" to a previously legally marketed device can be \"cleared\" by the FDA for marketing as long as the general and special controls, as described below, are met. The vast majority of new medical devices (99%) enter the marketplace via this process. The 510(k) pathway rarely requires clinical trials. The second regulatory pathway for new medical devices is the Premarket Approval process, described below, which is similar to the pathway for a new drug approval. Typically, clinical trials are required for this premarket approval pathway.<sup id=\"rdp-ebb-cite_ref-Zuckerman_2011_15-0\" class=\"reference\"><a href=\"#cite_note-Zuckerman_2011-15\" rel=\"external_link\">[15]<\/a><\/sup>\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Class_I:_General_controls\">Class I: General controls<\/span><\/h4>\n<p>Class I devices are subject to the least regulatory control. Class I devices are subject to \"General Controls\" as are Class II and Class III devices.<sup id=\"rdp-ebb-cite_ref-classification_13-1\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-controls_16-0\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-general_controls_17-0\" class=\"reference\"><a href=\"#cite_note-general_controls-17\" rel=\"external_link\">[17]<\/a><\/sup> General controls include provisions that relate to adulteration; misbranding; device registration and listing; premarket notification; banned devices; notification, including repair, replacement, or refund; records and reports; restricted devices; and good manufacturing practices.<sup id=\"rdp-ebb-cite_ref-general_controls_17-1\" class=\"reference\"><a href=\"#cite_note-general_controls-17\" rel=\"external_link\">[17]<\/a><\/sup> Class I devices are not intended to help support or sustain life or be substantially important in preventing impairment to human health, and may not present an unreasonable risk of illness or injury.<sup id=\"rdp-ebb-cite_ref-general_controls_17-2\" class=\"reference\"><a href=\"#cite_note-general_controls-17\" rel=\"external_link\">[17]<\/a><\/sup> Most Class I devices are exempt from the premarket notification and a few are also exempted from most good manufacturing practices regulation.<sup id=\"rdp-ebb-cite_ref-classification_13-2\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-controls_16-1\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-general_controls_17-3\" class=\"reference\"><a href=\"#cite_note-general_controls-17\" rel=\"external_link\">[17]<\/a><\/sup> Examples of Class I devices include elastic bandages, examination gloves, and hand-held surgical instruments.<sup id=\"rdp-ebb-cite_ref-controls_16-2\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup>\n<\/p>\n<h4><span class=\"mw-headline\" id=\"Class_II:_General_controls_with_special_controls\">Class II: General controls with special controls<\/span><\/h4>\n<p>Class II devices are those for which general controls alone cannot assure safety and effectiveness, and existing methods are available that provide such assurances.<sup id=\"rdp-ebb-cite_ref-classification_13-3\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-controls_16-3\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> In addition to complying with general controls, Class II devices are also subject to special controls.<sup id=\"rdp-ebb-cite_ref-controls_16-4\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> A few Class II devices are exempt from the premarket notification.<sup id=\"rdp-ebb-cite_ref-controls_16-5\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> Special controls may include special labeling requirements, mandatory performance standards and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Postmarketing_surveillance\" title=\"Postmarketing surveillance\" rel=\"external_link\" target=\"_blank\">postmarket surveillance<\/a>.<sup id=\"rdp-ebb-cite_ref-controls_16-6\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> Devices in Class II are held to a higher level of assurance than Class I devices, and are designed to perform as indicated without causing injury or harm to patient or user. Examples of Class II devices include acupuncture needles, powered wheelchairs, infusion pumps, air purifiers, and surgical drapes.<sup id=\"rdp-ebb-cite_ref-classification_13-4\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-controls_16-7\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-18\" class=\"reference\"><a href=\"#cite_note-18\" rel=\"external_link\">[18]<\/a><\/sup>\n<\/p>\n<h4><span id=\"rdp-ebb-Class_III:_General_controls.2C_Special_Controls_and_premarket_approval\"><\/span><span class=\"mw-headline\" id=\"Class_III:_General_controls,_Special_Controls_and_premarket_approval\">Class III: General controls, Special Controls and premarket approval<\/span><\/h4>\n<p>A Class III device is one for which insufficient information exists to assure safety and effectiveness solely through the general or special controls sufficient for Class I or Class II devices.<sup id=\"rdp-ebb-cite_ref-classification_13-5\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-controls_16-8\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> Such a device needs <a href=\"https:\/\/en.wikipedia.org\/wiki\/Premarket_approval#Premarket_approval_(PMA)\" class=\"mw-redirect\" title=\"Premarket approval\" rel=\"external_link\" target=\"_blank\">premarket approval<\/a>, a scientific review to ensure the device's safety and effectiveness, in addition to the general controls of Class I.<sup id=\"rdp-ebb-cite_ref-classification_13-6\" class=\"reference\"><a href=\"#cite_note-classification-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-controls_16-9\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> Class III devices are usually those that support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential, unreasonable risk of illness or injury.<sup id=\"rdp-ebb-cite_ref-controls_16-10\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup> Examples of Class III devices that currently require a premarket notification include implantable pacemaker, pulse generators, HIV diagnostic tests, automated external defibrillators, and endosseous implants.<sup id=\"rdp-ebb-cite_ref-controls_16-11\" class=\"reference\"><a href=\"#cite_note-controls-16\" rel=\"external_link\">[16]<\/a><\/sup>\n<\/p>\n<h3><span id=\"rdp-ebb-European_Union_.28EU.29_and_European_Free_Trade_Association_.28EFTA.29\"><\/span><span class=\"mw-headline\" id=\"European_Union_(EU)_and_European_Free_Trade_Association_(EFTA)\">European Union (EU) and European Free Trade Association (EFTA)<\/span><\/h3>\n<p>The classification of medical devices in the European Union is outlined in Article IX of the Council Directive 93\/42\/EEC. There are basically four classes, ranging from low risk to high risk.\n<\/p>\n<ul><li>Class I (including Is & Im)<\/li>\n<li>Class IIa<\/li>\n<li>Class IIb<\/li>\n<li>Class III<\/li><\/ul>\n<p>The authorization of medical devices is guaranteed by a Declaration of Conformity. This declaration is issued by the manufacturer itself, but for products in Class Is, Im, IIa, IIb or III, it must be verified by a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Certificate_of_Conformity\" class=\"mw-redirect\" title=\"Certificate of Conformity\" rel=\"external_link\" target=\"_blank\">Certificate of Conformity<\/a> issued by a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Notified_Body\" title=\"Notified Body\" rel=\"external_link\" target=\"_blank\">Notified Body<\/a>. A Notified Body is a public or private organisation that has been accredited to validate the compliance of the device to the European Directive. Medical devices that pertain to class I (on condition they do not require sterilization or do not measure a function) can be marketed purely by self-certification.\n<\/p><p>The European classification depends on rules that involve the medical device's duration of body contact, invasive character, use of an energy source, effect on the central circulation or nervous system, diagnostic impact, or incorporation of a medicinal product. Certified medical devices should have the <a href=\"https:\/\/en.wikipedia.org\/wiki\/CE_mark\" class=\"mw-redirect\" title=\"CE mark\" rel=\"external_link\" target=\"_blank\">CE mark<\/a> on the packaging, insert leaflets, etc.. These packagings should also show harmonised pictograms and <a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_EN_standards\" title=\"List of EN standards\" rel=\"external_link\" target=\"_blank\">EN<\/a> standardised logos to indicate essential features such as instructions for use, expiry date, manufacturer, sterile, don't reuse, etc.\n<\/p><p>In November 2018 the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Federal_Administrative_Court_(Switzerland)\" title=\"Federal Administrative Court (Switzerland)\" rel=\"external_link\" target=\"_blank\">Federal Administrative Court of Switzerland<\/a> decided that the \"Sympto\" app, used to analyze a woman's menstrual cycle, was a medical device because it calculates a fertility window for each woman using personal data. The manufacturer, Sympto-Therm Foundation, argued that this was a didactic, not a medical process. the court laid down that an <a href=\"https:\/\/en.wikipedia.org\/wiki\/Application_software\" title=\"Application software\" rel=\"external_link\" target=\"_blank\">app<\/a> is a medical device if it is to be used for any of the medical purposes provided by law, and creates or modifies health information by calculations or comparison,\n<p>providing information about an individual patient.<sup id=\"rdp-ebb-cite_ref-19\" class=\"reference\"><a href=\"#cite_note-19\" rel=\"external_link\">[19]<\/a><\/sup>\n<\/p>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Australia\">Australia<\/span><\/h3>\n<p>The classification of medical devices in Australia is outlined in section 41BD of the Therapeutic Goods Act 1989 and Regulation 3.2 of the Therapeutic Goods Regulations 2002, under control of the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Therapeutic_Goods_Administration\" title=\"Therapeutic Goods Administration\" rel=\"external_link\" target=\"_blank\">Therapeutic Goods Administration<\/a>. Similarly to the EU classification, they rank in several categories, by order of increasing risk and associated required level of control. Various rules identify the device's category<sup id=\"rdp-ebb-cite_ref-20\" class=\"reference\"><a href=\"#cite_note-20\" rel=\"external_link\">[20]<\/a><\/sup>\n<\/p>\n<table class=\"wikitable\" border=\"1\" style=\"\">\n<caption>Medical Devices Categories in Australia\n<\/caption>\n<tbody><tr>\n<th>Classification<\/th>\n<th>Level of Risk\n<\/th><\/tr>\n<tr>\n<td>Class I<\/td>\n<td>Low\n<\/td><\/tr>\n<tr>\n<td>Class I - measuring or Class I - supplied sterile or class IIa<\/td>\n<td>Low - medium\n<\/td><\/tr>\n<tr>\n<td>Class IIb<\/td>\n<td>Medium - high\n<\/td><\/tr>\n<tr>\n<td>Class III<\/td>\n<td>High\n<\/td><\/tr>\n<tr>\n<td>Active implantable medical devices (AIMD)<\/td>\n<td>High\n<\/td><\/tr><\/tbody><\/table>\n<h3><span class=\"mw-headline\" id=\"Iran\">Iran<\/span><\/h3>\n<p>With the fourth world engineering rating of over a thousand medical Devices,<a href=\"https:\/\/en.wikipedia.org\/wiki\/Iran\" title=\"Iran\" rel=\"external_link\" target=\"_blank\">Iran<\/a> produces about 2,000 species of medical devices and medical supplies such as appliances and dental supplies and all sorts of disposable sterile medical stuff,laboratory machines and all kinds of Biomaterials and dental implants and 400 medical products are produced at the C and D risk class which all of them are licensed by the Iranian Health Ministry in terms of safety and performance based on EU standards.\n<\/p><p>Iranian medical Devices products are produced according to the <a href=\"https:\/\/en.wikipedia.org\/wiki\/European_Union\" title=\"European Union\" rel=\"external_link\" target=\"_blank\">European<\/a> Union standards so the quality of products, skilled labour, access to the technologies of the world and the low price of products over the European countries are among the important features of these products and in these respects it is competitive with the products of European countries.\n<\/p><p>\u200fOn cooperation with active commercial partners in the European Union, Iran exports medical devices and supplies which has Union\u2019s standards and <a href=\"https:\/\/en.wikipedia.org\/wiki\/CE_marking\" title=\"CE marking\" rel=\"external_link\" target=\"_blank\">CE Logo<\/a> to the applicant countries including 40 Asian and European countries, some of which are in the rest of the world by transferring technology from Iran to other commercial partners.\n<\/p><p>Among the ways that Iranian producers do for exporting their products to foreign countries is exporting to foreign countries by placing products in the name of the country as that of manufacture (Made in Iran) or production of products in and packaging it in the name of the country's name and their exportation which is very welcomed by the European countries because of the contributions of other countries. It will also include the establishment of a joint production line between business partners and Iranian producing companies to manufacture and produce products to other applicants, from other production methods and export of Iranian devices and medical supplies.<sup id=\"rdp-ebb-cite_ref-21\" class=\"reference\"><a href=\"#cite_note-21\" rel=\"external_link\">[21]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Technological_security_issues\">Technological security issues<\/span><\/h2>\n<p>Medical devices such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Artificial_cardiac_pacemaker\" title=\"Artificial cardiac pacemaker\" rel=\"external_link\" target=\"_blank\">pacemakers<\/a>, insulin pumps, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Operating_room\" class=\"mw-redirect\" title=\"Operating room\" rel=\"external_link\" target=\"_blank\">operating room<\/a> monitors, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Defibrillators\" class=\"mw-redirect\" title=\"Defibrillators\" rel=\"external_link\" target=\"_blank\">defibrillators<\/a>, and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Surgical_instruments\" class=\"mw-redirect\" title=\"Surgical instruments\" rel=\"external_link\" target=\"_blank\">surgical instruments<\/a>, including deep-brain stimulators, can incorporate the ability to transmit vital <a href=\"https:\/\/en.wikipedia.org\/wiki\/Health_information\" class=\"mw-redirect\" title=\"Health information\" rel=\"external_link\" target=\"_blank\">health information<\/a> from a patient's body to <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_professionals\" class=\"mw-redirect\" title=\"Medical professionals\" rel=\"external_link\" target=\"_blank\">medical professionals<\/a>.<sup id=\"rdp-ebb-cite_ref-22\" class=\"reference\"><a href=\"#cite_note-22\" rel=\"external_link\">[22]<\/a><\/sup> Some of these devices can be remotely controlled. This has engendered concern about privacy and security issues,<sup id=\"rdp-ebb-cite_ref-23\" class=\"reference\"><a href=\"#cite_note-23\" rel=\"external_link\">[23]<\/a><\/sup> <a href=\"https:\/\/en.wikipedia.org\/wiki\/Human_error\" title=\"Human error\" rel=\"external_link\" target=\"_blank\">human error<\/a>, and technical glitches with this technology. While only a few studies have looked at the susceptibility of medical devices to hacking, there is a risk.<sup id=\"rdp-ebb-cite_ref-24\" class=\"reference\"><a href=\"#cite_note-24\" rel=\"external_link\">[24]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-25\" class=\"reference\"><a href=\"#cite_note-25\" rel=\"external_link\">[25]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-26\" class=\"reference\"><a href=\"#cite_note-26\" rel=\"external_link\">[26]<\/a><\/sup> In 2008, computer scientists proved that pacemakers and defibrillators can be hacked wirelessly via radio hardware, an antenna, and a personal computer.<sup id=\"rdp-ebb-cite_ref-27\" class=\"reference\"><a href=\"#cite_note-27\" rel=\"external_link\">[27]<\/a><\/sup> These researchers showed they could shut down a combination heart defibrillator and pacemaker and reprogram it to deliver potentially lethal shocks or run out its battery. Jay Radcliff, a security researcher interested in the security of medical devices, raised fears about the safety of these devices. He shared his concerns at the Black Hat security conference.<sup id=\"rdp-ebb-cite_ref-28\" class=\"reference\"><a href=\"#cite_note-28\" rel=\"external_link\">[28]<\/a><\/sup> Radcliff fears that the devices are vulnerable and has found that a lethal attack is possible against those with insulin pumps and glucose monitors. Some medical device makers downplay the threat from such attacks and argue that the demonstrated attacks have been performed by skilled security researchers and are unlikely to occur in the real world. At the same time, other makers have asked software security experts to investigate the safety of their devices.<sup id=\"rdp-ebb-cite_ref-29\" class=\"reference\"><a href=\"#cite_note-29\" rel=\"external_link\">[29]<\/a><\/sup> As recently as June 2011, security experts showed that by using readily available hardware and a user manual, a scientist could both tap into the information on the system of a wireless insulin pump in combination with a glucose monitor. With the PIN of the device, the scientist could wirelessly control the dosage of the insulin.<sup id=\"rdp-ebb-cite_ref-ReferenceA_30-0\" class=\"reference\"><a href=\"#cite_note-ReferenceA-30\" rel=\"external_link\">[30]<\/a><\/sup> Anand Raghunathan, a researcher in this study, explains that medical devices are getting smaller and lighter so that they can be easily worn. The downside is that additional security features would put an extra strain on the battery and size and drive up prices. Dr. William Maisel offered some thoughts on the motivation to engage in this activity. Motivation to do this hacking might include acquisition of private information for financial gain or competitive advantage; damage to a device manufacturer's reputation; sabotage; intent to inflict financial or personal injury or just satisfaction for the attacker.<sup id=\"rdp-ebb-cite_ref-31\" class=\"reference\"><a href=\"#cite_note-31\" rel=\"external_link\">[31]<\/a><\/sup> Researchers suggest a few safeguards. One would be to use rolling codes. Another solution is to use a technology called \"body-coupled communication\" that uses the human skin as a wave guide for wireless communication. On 28 December 2016 the US <a href=\"https:\/\/en.wikipedia.org\/wiki\/Food_and_Drug_Administration\" title=\"Food and Drug Administration\" rel=\"external_link\" target=\"_blank\">Food and Drug Administration<\/a> released its recommendations that are not legally enforceable for how medical <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_device_manufacturing\" title=\"Medical device manufacturing\" rel=\"external_link\" target=\"_blank\">device manufacturers<\/a> should maintain the security of Internet-connected devices.<sup id=\"rdp-ebb-cite_ref-32\" class=\"reference\"><a href=\"#cite_note-32\" rel=\"external_link\">[32]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-33\" class=\"reference\"><a href=\"#cite_note-33\" rel=\"external_link\">[33]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Standardization_and_regulatory_concerns\">Standardization and regulatory concerns<\/span><\/h2>\n<p>The <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Organization_for_Standardization\" title=\"International Organization for Standardization\" rel=\"external_link\" target=\"_blank\">ISO<\/a> standards for medical devices are covered by ICS 11.100.20 and 11.040.01.<sup id=\"rdp-ebb-cite_ref-ISO11.100_34-0\" class=\"reference\"><a href=\"#cite_note-ISO11.100-34\" rel=\"external_link\">[34]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-meg_35-0\" class=\"reference\"><a href=\"#cite_note-meg-35\" rel=\"external_link\">[35]<\/a><\/sup> The quality and <a href=\"https:\/\/en.wikipedia.org\/wiki\/Risk_management\" title=\"Risk management\" rel=\"external_link\" target=\"_blank\">risk management<\/a> regarding the topic for regulatory purposes is convened by <a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO_13485\" title=\"ISO 13485\" rel=\"external_link\" target=\"_blank\">ISO 13485<\/a> and <a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO_14971\" title=\"ISO 14971\" rel=\"external_link\" target=\"_blank\">ISO 14971<\/a>. ISO 13485:2003 is applicable to all providers and manufacturers of medical devices, components, contract services and distributors of medical devices. The standard is the basis for <a href=\"https:\/\/en.wikipedia.org\/wiki\/Regulatory_compliance\" title=\"Regulatory compliance\" rel=\"external_link\" target=\"_blank\">regulatory compliance<\/a> in local markets, and most export markets.<sup id=\"rdp-ebb-cite_ref-36\" class=\"reference\"><a href=\"#cite_note-36\" rel=\"external_link\">[36]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-37\" class=\"reference\"><a href=\"#cite_note-37\" rel=\"external_link\">[37]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-38\" class=\"reference\"><a href=\"#cite_note-38\" rel=\"external_link\">[38]<\/a><\/sup> Additionally, <a href=\"https:\/\/en.wikipedia.org:2008\/wiki\/ISO_9001:2008\" class=\"mw-redirect\" title=\"ISO 9001:2008\" rel=\"external_link\" target=\"_blank\">ISO 9001:2008<\/a> sets precedence because it signifies that a company engages in the creation of new products. It requires that the development of manufactured products have an approval process and a set of rigorous quality standards and development records before the product is distributed.<sup id=\"rdp-ebb-cite_ref-39\" class=\"reference\"><a href=\"#cite_note-39\" rel=\"external_link\">[39]<\/a><\/sup> Further standards are <a href=\"https:\/\/en.wikipedia.org\/wiki\/IEC_60601-1\" class=\"mw-redirect\" title=\"IEC 60601-1\" rel=\"external_link\" target=\"_blank\">IEC 60601-1<\/a> which is for electrical devices (mains-powered as well as battery powered), <a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_EN_standards\" title=\"List of EN standards\" rel=\"external_link\" target=\"_blank\">EN 45502-1<\/a> which is for Active implantable medical devices, and <a href=\"https:\/\/en.wikipedia.org\/wiki\/IEC_62304\" title=\"IEC 62304\" rel=\"external_link\" target=\"_blank\">IEC 62304<\/a> for medical software. The <a href=\"https:\/\/en.wikipedia.org\/wiki\/Food_and_Drug_Administration_(United_States)\" class=\"mw-redirect\" title=\"Food and Drug Administration (United States)\" rel=\"external_link\" target=\"_blank\">US FDA<\/a> also published a series of guidances for industry regarding this topic against <a href=\"https:\/\/en.wikipedia.org\/wiki\/21_CFR_820\" class=\"mw-redirect\" title=\"21 CFR 820\" rel=\"external_link\" target=\"_blank\">21 CFR 820<\/a> Subchapter H\u2014Medical Devices.<sup id=\"rdp-ebb-cite_ref-dp_40-0\" class=\"reference\"><a href=\"#cite_note-dp-40\" rel=\"external_link\">[40]<\/a><\/sup> Subpart B includes quality system requirements, an important component of which are <a href=\"https:\/\/en.wikipedia.org\/wiki\/Design_controls\" title=\"Design controls\" rel=\"external_link\" target=\"_blank\">design controls<\/a> (21 CFR 820.30). To meet the demands of these industry regulation standards, a growing number of medical device distributors are putting the complaint management process at the forefront of their <a href=\"https:\/\/en.wikipedia.org\/wiki\/Quality_management\" title=\"Quality management\" rel=\"external_link\" target=\"_blank\">quality management<\/a> practices. This approach further mitigates risks and increases visibility of quality issues.<sup id=\"rdp-ebb-cite_ref-41\" class=\"reference\"><a href=\"#cite_note-41\" rel=\"external_link\">[41]<\/a><\/sup>\n<\/p><p>Starting in the late 1980s<sup id=\"rdp-ebb-cite_ref-42\" class=\"reference\"><a href=\"#cite_note-42\" rel=\"external_link\">[42]<\/a><\/sup> the FDA increased its involvement in reviewing the development of medical device software. The precipitant for change was a radiation therapy device (<a href=\"https:\/\/en.wikipedia.org\/wiki\/Therac-25\" title=\"Therac-25\" rel=\"external_link\" target=\"_blank\">Therac-25<\/a>) that overdosed patients because of software coding errors.<sup id=\"rdp-ebb-cite_ref-43\" class=\"reference\"><a href=\"#cite_note-43\" rel=\"external_link\">[43]<\/a><\/sup> FDA is now focused on regulatory oversight on medical device software development process and system-level testing.<sup id=\"rdp-ebb-cite_ref-44\" class=\"reference\"><a href=\"#cite_note-44\" rel=\"external_link\">[44]<\/a><\/sup>\n<\/p><p>A 2011 study by Dr. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Diana_Zuckerman\" title=\"Diana Zuckerman\" rel=\"external_link\" target=\"_blank\">Diana Zuckerman<\/a> and Paul Brown of the <a href=\"https:\/\/en.wikipedia.org\/wiki\/National_Research_Center_for_Women_and_Families\" class=\"mw-redirect\" title=\"National Research Center for Women and Families\" rel=\"external_link\" target=\"_blank\">National Research Center for Women and Families<\/a>, and Dr. Steven Nissen of the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cleveland_Clinic\" title=\"Cleveland Clinic\" rel=\"external_link\" target=\"_blank\">Cleveland Clinic<\/a>, published in the <i><a href=\"https:\/\/en.wikipedia.org\/wiki\/Archives_of_Internal_Medicine\" class=\"mw-redirect\" title=\"Archives of Internal Medicine\" rel=\"external_link\" target=\"_blank\">Archives of Internal Medicine<\/a><\/i>, showed that most medical devices recalled in the last five years for \"serious health problems or death\" had been previously approved by the FDA using the less stringent, and cheaper, 510(k) process. In a few cases the devices had been deemed so low-risk that they did not need FDA regulation. Of the 113 devices recalled, 35 were for cardiovascular issues.<sup id=\"rdp-ebb-cite_ref-Zuckerman_2011_15-1\" class=\"reference\"><a href=\"#cite_note-Zuckerman_2011-15\" rel=\"external_link\">[15]<\/a><\/sup> This may lead to a reevaluation of FDA procedures and better oversight.\n<\/p><p><span id=\"rdp-ebb-Medical_Device_Single_Audit_Program\"><\/span><span id=\"rdp-ebb-MDSAP\"><\/span>\n<p>In 2014-2015 a new international agreement, the Medical Device Single Audit Program (MDSAP), was put in place with five participant countries: Australia, Brazil, Canada, Japan, and the United States. The aim of this program was to \"develop a process that allows a single audit, or inspection to ensure the medical device regulatory requirements for all five countries are satisfied\".<sup id=\"rdp-ebb-cite_ref-trautman2015_45-0\" class=\"reference\"><a href=\"#cite_note-trautman2015-45\" rel=\"external_link\">[45]<\/a><\/sup>\n<\/p>\n<\/p><p>In 2018, an investigation involving journalists across 36 countries coordinated by the <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Consortium_of_Investigative_Journalists\" title=\"International Consortium of Investigative Journalists\" rel=\"external_link\" target=\"_blank\">International Consortium of Investigative Journalists<\/a> (ICIJ) prompted calls for reform in the United States, particularly around the 510(k) <a href=\"https:\/\/en.wikipedia.org\/wiki\/Substantial_equivalence\" title=\"Substantial equivalence\" rel=\"external_link\" target=\"_blank\">substantial equivalence<\/a> process;<sup id=\"rdp-ebb-cite_ref-46\" class=\"reference\"><a href=\"#cite_note-46\" rel=\"external_link\">[46]<\/a><\/sup> the investigation prompted similar calls in the UK and Europe Union.<sup id=\"rdp-ebb-cite_ref-47\" class=\"reference\"><a href=\"#cite_note-47\" rel=\"external_link\">[47]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Packaging_standards\">Packaging standards<\/span><\/h3>\n<p>Medical device <a href=\"https:\/\/en.wikipedia.org\/wiki\/Packaging\" class=\"mw-redirect\" title=\"Packaging\" rel=\"external_link\" target=\"_blank\">packaging<\/a> is highly regulated. Often medical devices and products are sterilized in the package.<sup id=\"rdp-ebb-cite_ref-48\" class=\"reference\"><a href=\"#cite_note-48\" rel=\"external_link\">[48]<\/a><\/sup>\nSterility must be maintained throughout distribution to allow immediate use by physicians. A series of special packaging tests measure the ability of the package to maintain sterility. Relevant standards include:\n<\/p>\n<ul><li>ASTM D1585 \u2013 <i>Guide for Integrity Testing of Porous Medical Packages<\/i><\/li>\n<li>ASTM F2097 \u2013 <i>Standard Guide for Design and Evaluation of Primary Flexible Packaging for Medical Products<\/i><\/li>\n<li>ASTM F3475-11 \u2013 Standard Guide for Biocompatibility Evaluation of Medical Device Packaging Materials<sup id=\"rdp-ebb-cite_ref-49\" class=\"reference\"><a href=\"#cite_note-49\" rel=\"external_link\">[49]<\/a><\/sup><\/li>\n<li>EN 868 <i>Packaging materials and systems for medical devices to be sterilized, General requirements and test methods<\/i><\/li>\n<li>ISO 11607 <i>Packaging for terminally sterilized medical devices<\/i><\/li><\/ul>\n<p><a href=\"https:\/\/en.wikipedia.org\/wiki\/Package_testing\" title=\"Package testing\" rel=\"external_link\" target=\"_blank\">Package testing<\/a> documents and ensures that packages meet regulations and end-use requirements. Manufacturing processes must be controlled and validated to ensure consistent performance.<sup id=\"rdp-ebb-cite_ref-50\" class=\"reference\"><a href=\"#cite_note-50\" rel=\"external_link\">[50]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-51\" class=\"reference\"><a href=\"#cite_note-51\" rel=\"external_link\">[51]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Biocompatibility_standards\">Biocompatibility standards<\/span><\/h3>\n<ul><li><a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO_10993\" title=\"ISO 10993\" rel=\"external_link\" target=\"_blank\">ISO 10993<\/a> - Biological Evaluation of Medical Devices<\/li><\/ul>\n<h3><span class=\"mw-headline\" id=\"Cleanliness_standards\">Cleanliness standards<\/span><\/h3>\n<p>Medical device cleanliness has come under greater scrutiny since 2000, when Sulzer Orthopedics recalled several thousand metal hip implants that contained a manufacturing residue.<sup id=\"rdp-ebb-cite_ref-52\" class=\"reference\"><a href=\"#cite_note-52\" rel=\"external_link\">[52]<\/a><\/sup> Based on this event, ASTM established a new task group (F04.15.17) for established test methods, guidance documents, and other standards to address cleanliness of medical devices. This task group has issued two standards for permanent implants to date: 1. ASTM F2459: Standard test method for extracting residue from metallic medical components and quantifying via gravimetric analysis<sup id=\"rdp-ebb-cite_ref-53\" class=\"reference\"><a href=\"#cite_note-53\" rel=\"external_link\">[53]<\/a><\/sup> 2. ASTM F2847: Standard Practice for Reporting and Assessment of Residues on Single Use Implants<sup id=\"rdp-ebb-cite_ref-54\" class=\"reference\"><a href=\"#cite_note-54\" rel=\"external_link\">[54]<\/a><\/sup> 3. ASTM F3172: Standard Guide for Validating Cleaning Processes Used During the Manufacture of Medical Devices <sup id=\"rdp-ebb-cite_ref-astm.org_55-0\" class=\"reference\"><a href=\"#cite_note-astm.org-55\" rel=\"external_link\">[55]<\/a><\/sup>\n<\/p><p>In addition, the cleanliness of re-usable devices has led to a series of standards, including:\n<\/p>\n<ul><li>ASTM E2314: <i>Standard Test Method for Determination of Effectiveness of Cleaning Processes for Reusable Medical Instruments Using a Microbiologic Method (Simulated Use Test)\"<sup id=\"rdp-ebb-cite_ref-56\" class=\"reference\"><a href=\"#cite_note-56\" rel=\"external_link\">[56]<\/a><\/sup><\/i><\/li>\n<li>ASTM D7225: <i>Standard Guide for Blood Cleaning Efficiency of Detergents and Washer-Disinfectors<\/i><sup id=\"rdp-ebb-cite_ref-57\" class=\"reference\"><a href=\"#cite_note-57\" rel=\"external_link\">[57]<\/a><\/sup><\/li>\n<li>ASTM F3208: <i>Standard Guide for Selecting Test Soils for Validation of Cleaning Methods for Reusable Medical Devices<\/i><sup id=\"rdp-ebb-cite_ref-astm.org_55-1\" class=\"reference\"><a href=\"#cite_note-astm.org-55\" rel=\"external_link\">[55]<\/a><\/sup><\/li><\/ul>\n<p>The ASTM F04.15.17 task group is working on several new standards that involve designing implants for cleaning, selection and testing of brushes for cleaning reusable devices, and cleaning assessment of medical devices made by additive manufacturing.<sup id=\"rdp-ebb-cite_ref-58\" class=\"reference\"><a href=\"#cite_note-58\" rel=\"external_link\">[58]<\/a><\/sup> Additionally, the FDA is establishing new guidelines for reprocessing reusable medical devices, such as orthoscopic shavers, endoscopes, and suction tubes.<sup id=\"rdp-ebb-cite_ref-59\" class=\"reference\"><a href=\"#cite_note-59\" rel=\"external_link\">[59]<\/a><\/sup>\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Mobile_medical_applications\">Mobile medical applications<\/span><\/h3>\n<p>With the rise of smartphone usage in the medical space, in 2013, the FDA issued to regulate <a href=\"https:\/\/en.wikipedia.org\/wiki\/Mobile_medical_apps\" class=\"mw-redirect\" title=\"Mobile medical apps\" rel=\"external_link\" target=\"_blank\">mobile medical applications<\/a> and protect users from their unintended use, soon followed by European and other regulatory agencies. This guidance distinguishes the apps subjected to regulation based on the marketing claims of the apps.<sup id=\"rdp-ebb-cite_ref-60\" class=\"reference\"><a href=\"#cite_note-60\" rel=\"external_link\">[60]<\/a><\/sup> Incorporation of the guidelines during the development phase of such apps can be considered as developing a medical device; the regulations have to adapt and propositions for expedite approval may be required due to the nature of 'versions' of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Mobile_medical_apps\" class=\"mw-redirect\" title=\"Mobile medical apps\" rel=\"external_link\" target=\"_blank\">mobile application<\/a> development.<sup id=\"rdp-ebb-cite_ref-61\" class=\"reference\"><a href=\"#cite_note-61\" rel=\"external_link\">[61]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-62\" class=\"reference\"><a href=\"#cite_note-62\" rel=\"external_link\">[62]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Academic_resources\">Academic resources<\/span><\/h2>\n<ul><li><i><a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_%26_Biological_Engineering_%26_Computing\" title=\"Medical & Biological Engineering & Computing\" rel=\"external_link\" target=\"_blank\">Medical & Biological Engineering & Computing<\/a><\/i><\/li>\n<li><i><a href=\"https:\/\/en.wikipedia.org\/wiki\/Expert_Review_of_Medical_Devices\" title=\"Expert Review of Medical Devices\" rel=\"external_link\" target=\"_blank\">Expert Review of Medical Devices<\/a><\/i><\/li>\n<li><i><\/i><sup id=\"rdp-ebb-cite_ref-jce_63-0\" class=\"reference\"><a href=\"#cite_note-jce-63\" rel=\"external_link\">[63]<\/a><\/sup><\/li><\/ul>\n<h3><span class=\"mw-headline\" id=\"University_Based_Research_Packaging_Institutes\">University Based Research Packaging Institutes<\/span><\/h3>\n<ul><li><a href=\"https:\/\/en.wikipedia.org\/wiki\/University_of_Minnesota\" title=\"University of Minnesota\" rel=\"external_link\" target=\"_blank\">University of Minnesota<\/a> - Medical Devices Center (MDC)<\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/University_of_Strathclyde\" title=\"University of Strathclyde\" rel=\"external_link\" target=\"_blank\">University of Strathclyde<\/a> - Strathclyde Institute of Medical Devices (SIMD)<\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Flinders_University\" title=\"Flinders University\" rel=\"external_link\" target=\"_blank\">Flinders University<\/a> - Medical Device Research Institute (MDRI)<\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Michigan_State_University\" title=\"Michigan State University\" rel=\"external_link\" target=\"_blank\">Michigan State University<\/a> - School of Packaging (SoP)<sup id=\"rdp-ebb-cite_ref-64\" class=\"reference\"><a href=\"#cite_note-64\" rel=\"external_link\">[64]<\/a><\/sup><\/li><\/ul>\n<h2><span class=\"mw-headline\" id=\"See_also\">See also<\/span><\/h2>\n<div class=\"div-col columns column-width\" style=\"-moz-column-width: 30em; -webkit-column-width: 30em; column-width: 30em;\">\n<ul><li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Biomedical_engineering\" title=\"Biomedical engineering\" rel=\"external_link\" target=\"_blank\"> Biomedical engineering<\/a> – Application of engineering principles and design concepts to medicine and biology for healthcare purposes<\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Biomedical_equipment_technician\" title=\"Biomedical equipment technician\" rel=\"external_link\" target=\"_blank\"> Biomedical equipment technician<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Clinical_engineering\" title=\"Clinical engineering\" rel=\"external_link\" target=\"_blank\"> Clinical engineering<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Design_history_file\" title=\"Design history file\" rel=\"external_link\" target=\"_blank\"> Design history file<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Durable_medical_equipment\" title=\"Durable medical equipment\" rel=\"external_link\" target=\"_blank\"> Durable medical equipment<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Electromagnetic_compatibility\" title=\"Electromagnetic compatibility\" rel=\"external_link\" target=\"_blank\"> Electromagnetic compatibility<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Electronic_health_record\" title=\"Electronic health record\" rel=\"external_link\" target=\"_blank\"> Electronic health record<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Federal_Institute_for_Drugs_and_Medical_Devices\" title=\"Federal Institute for Drugs and Medical Devices\" rel=\"external_link\" target=\"_blank\"> Federal Institute for Drugs and Medical Devices<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/In_vitro_diagnostics\" class=\"mw-redirect\" title=\"In vitro diagnostics\" rel=\"external_link\" target=\"_blank\"> In vitro diagnostics<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/GHTF\" class=\"mw-redirect\" title=\"GHTF\" rel=\"external_link\" target=\"_blank\"> GHTF<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Health_Level_7\" title=\"Health Level 7\" rel=\"external_link\" target=\"_blank\"> Health Level 7<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Home_medical_equipment\" title=\"Home medical equipment\" rel=\"external_link\" target=\"_blank\"> Home medical equipment<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Implant_(medicine)\" title=\"Implant (medicine)\" rel=\"external_link\" target=\"_blank\"> Implant (medicine)<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO_13485\" title=\"ISO 13485\" rel=\"external_link\" target=\"_blank\"> ISO 13485<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_common_EMC_test_standards\" title=\"List of common EMC test standards\" rel=\"external_link\" target=\"_blank\"> List of common EMC test standards<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_Devices_Directive\" title=\"Medical Devices Directive\" rel=\"external_link\" target=\"_blank\"> Medical Devices Directive<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_device_hijack\" title=\"Medical device hijack\" rel=\"external_link\" target=\"_blank\"> Medical device hijack<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_equipment\" title=\"Medical equipment\" rel=\"external_link\" target=\"_blank\"> Medical equipment<\/a> – Equipment designed to aid in the diagnosis, monitoring or treatment of medical conditions<\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_logistics\" title=\"Medical logistics\" rel=\"external_link\" target=\"_blank\"> Medical logistics<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_software\" title=\"Medical software\" rel=\"external_link\" target=\"_blank\"> Medical software<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Safety_engineering\" title=\"Safety engineering\" rel=\"external_link\" target=\"_blank\"> Safety engineering<\/a><\/li>\n<li><i>Section 201(h)<\/i> of <a href=\"https:\/\/en.wikipedia.org\/wiki\/Federal_Food,_Drug,_and_Cosmetic_Act\" title=\"Federal Food, Drug, and Cosmetic Act\" rel=\"external_link\" target=\"_blank\"> Federal Food, Drug, and Cosmetic Act<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Telemedicine\" title=\"Telemedicine\" rel=\"external_link\" target=\"_blank\"> Telemedicine<\/a> – Medical care by telecommunication<\/li><\/ul>\n<\/div>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist columns references-column-width\" style=\"-moz-column-width: 30em; -webkit-column-width: 30em; column-width: 30em; list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-1\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-1\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.acmite.com\/market-reports\/medicals\/world-medical-devices-market.html\" target=\"_blank\">\"Market Report: World Medical Devices Market\"<\/a>. Acmite Market Intelligence. 2014<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Market+Report%3A+World+Medical+Devices+Market&rft.pub=Acmite+Market+Intelligence&rft.date=2014&rft_id=http%3A%2F%2Fwww.acmite.com%2Fmarket-reports%2Fmedicals%2Fworld-medical-devices-market.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><\/span>\n<\/li>\n<li id=\"cite_note-bemd-2\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-bemd_2-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-bemd_2-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Wong, K., Tu, J., Sun, Z., and Dissanayake, D. W. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.worldscientific.com\/worldscibooks\/10.1142\/8621\" target=\"_blank\">\"Methods in Research and Development of Biomedical Devices\"<\/a>. World Scientific Publishing<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">29 May<\/span> 2013<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Methods+in+Research+and+Development+of+Biomedical+Devices&rft.pub=World+Scientific+Publishing&rft.au=Wong%2C+K.%2C+Tu%2C+J.%2C+Sun%2C+Z.%2C+and+Dissanayake%2C+D.+W.&rft_id=http%3A%2F%2Fwww.worldscientific.com%2Fworldscibooks%2F10.1142%2F8621&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><span class=\"citation-comment\" style=\"display:none; color:#33aa33; margin-left:0.3em\">CS1 maint: Multiple names: authors list (<a href=\"https:\/\/en.wikipedia.org\/wiki\/Category:CS1_maint:_Multiple_names:_authors_list\" title=\"Category:CS1 maint: Multiple names: authors list\" rel=\"external_link\" target=\"_blank\">link<\/a>) <\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-3\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-3\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=CELEX:31985Y0604%2801%29:EN:HTML\" target=\"_blank\">\"Eur-lex Europa\"<\/a>. 2005<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Eur-lex+Europa&rft.date=2005&rft_id=http%3A%2F%2Feur-lex.europa.eu%2FLexUriServ%2FLexUriServ.do%3Furi%3DCELEX%3A31985Y0604%252801%2529%3AEN%3AHTML&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-:0-4\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-:0_4-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-:0_4-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF\" target=\"_blank\">\"Directive 2007\/47\/ec of the European parliament and of the council\"<\/a>. <i>Eur-lex Europa<\/i>. 5 September 2007<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Eur-lex+Europa&rft.atitle=Directive+2007%2F47%2Fec+of+the+European+parliament+and+of+the+council&rft.date=2007-09-05&rft_id=http%3A%2F%2Feur-lex.europa.eu%2FLexUriServ%2FLexUriServ.do%3Furi%3DOJ%3AL%3A2007%3A247%3A0021%3A0055%3Aen%3APDF&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-5\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-5\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/ec.europa.eu\/health\/medical-devices\/documents\/revision\/index_en.htm\" target=\"_blank\">\"Revision of the medical device directives\"<\/a>. European Commission. 2013<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Revision+of+the+medical+device+directives&rft.pub=European+Commission&rft.date=2013&rft_id=http%3A%2F%2Fec.europa.eu%2Fhealth%2Fmedical-devices%2Fdocuments%2Frevision%2Findex_en.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-6\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-6\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">US Food and Drug Administration,\n<a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/Overview\/ClassifyYourDevice\/ucm051512.htm\" target=\"_blank\">\"Is The Product A Medical Device?\"<\/a><\/span>\n<\/li>\n<li id=\"cite_note-7\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-7\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.gpo.gov\/fdsys\/pkg\/FR-2013-08-06\/pdf\/2013-19020.pdf\" target=\"_blank\">\"<i>Federal Register<\/i> Vol 78, No 151, page 47712\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. U.S. Government Publishing Office. 6 August 2013<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">17 February<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Federal+Register+Vol+78%2C+No+151%2C+page+47712&rft.pub=U.S.+Government+Publishing+Office&rft.date=2013-08-06&rft_id=http%3A%2F%2Fwww.gpo.gov%2Ffdsys%2Fpkg%2FFR-2013-08-06%2Fpdf%2F2013-19020.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-8\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-8\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">FDA <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/MedicalDevices\/DeviceRegulationandGuidance\/GuidanceDocuments\/UCM263366.pdf\" target=\"_blank\">Mobile Medical Applications: Guidance for Industry and Food and Drug Administration Staff<\/a><\/span>\n<\/li>\n<li id=\"cite_note-9\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-9\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Piccardo, Carmelita (28 July 2014). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.npiservices.com\/fda-eases-product-development\/\" target=\"_blank\">\"FDA Eases the Way for New Product Development\"<\/a>. NPI Services, Inc<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">17 February<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=FDA+Eases+the+Way+for+New+Product+Development&rft.pub=NPI+Services%2C+Inc&rft.date=2014-07-28&rft.aulast=Piccardo&rft.aufirst=Carmelita&rft_id=http%3A%2F%2Fwww.npiservices.com%2Ffda-eases-product-development%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-Canada_regulations-10\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-Canada_regulations_10-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-Canada_regulations_10-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/laws-lois.justice.gc.ca\/PDF\/SOR-98-282.pdf\" target=\"_blank\">\"Medical Devices Regulations SOR\/98-282\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. Department of Justice Canada. 16 December 2011<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">25 August<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Medical+Devices+Regulations+SOR%2F98-282&rft.pub=Department+of+Justice+Canada&rft.date=2011-12-16&rft_id=http%3A%2F%2Flaws-lois.justice.gc.ca%2FPDF%2FSOR-98-282.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-HealthCanada-11\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-HealthCanada_11-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-HealthCanada_11-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.hc-sc.gc.ca\/dhp-mps\/md-im\/applic-demande\/guide-ld\/gd_rbc_non_ivdd_lg_scr_autres_idiv-eng.php\" target=\"_blank\">\"Guidance Document - Guidance on the Risk-based Classification System for Non-In Vitro Diagnostic Devices (non-IVDDs)\"<\/a>. Health Canada. 2015-04-23<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2016-04-21<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Guidance+Document+-+Guidance+on+the+Risk-based+Classification+System+for+Non-In+Vitro+Diagnostic+Devices+%28non-IVDDs%29&rft.pub=Health+Canada&rft.date=2015-04-23&rft_id=http%3A%2F%2Fwww.hc-sc.gc.ca%2Fdhp-mps%2Fmd-im%2Fapplic-demande%2Fguide-ld%2Fgd_rbc_non_ivdd_lg_scr_autres_idiv-eng.php&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-12\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-12\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation magazine\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.cadth.ca\/sites\/default\/files\/pdf\/hta_thupdate_issue5_e.pdf\" target=\"_blank\">\"Medical Device Regulation In Canada: A Primer\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. <i>Health Technology Update<\/i>. No. 5. Ottawa: Canadian Agency for Drugs and Technologies in Health. 2007-01-12. pp. 2\u20133<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2016-04-21<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Health+Technology+Update&rft.atitle=Medical+Device+Regulation+In+Canada%3A+A+Primer&rft.issue=5&rft.pages=2-3&rft.date=2007-01-12&rft_id=https%3A%2F%2Fwww.cadth.ca%2Fsites%2Fdefault%2Ffiles%2Fpdf%2Fhta_thupdate_issue5_e.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-classification-13\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-classification_13-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-classification_13-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-classification_13-2\" rel=\"external_link\"><sup><i><b>c<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-classification_13-3\" rel=\"external_link\"><sup><i><b>d<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-classification_13-4\" rel=\"external_link\"><sup><i><b>e<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-classification_13-5\" rel=\"external_link\"><sup><i><b>f<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-classification_13-6\" rel=\"external_link\"><sup><i><b>g<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/Overview\/ClassifyYourDevice\/default.htm\" target=\"_blank\">\"Device Classification\"<\/a>. <i>Medical Devices<\/i>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2010-10-15<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Medical+Devices&rft.atitle=Device+Classification&rft_id=http%3A%2F%2Fwww.fda.gov%2FMedicalDevices%2FDeviceRegulationandGuidance%2FOverview%2FClassifyYourDevice%2Fdefault.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-14\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-14\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.accessdata.fda.gov\/scripts\/cdrh\/cfdocs\/cfCFR\/CFRSearch.cfm?CFRPart=860\" target=\"_blank\">\"Title 21\u2014Food and drugs: Chapter i\u2014Food and drug administration: Department of health and human services: Subchapter H\u2014Medical devices: Part 860 Medical device classification procedures\"<\/a>. <i>CFR \u2013 Code of Federal Regulations Title 21<\/i>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 Oct<\/span> 2010<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=CFR+%E2%80%93+Code+of+Federal+Regulations+Title+21&rft.atitle=Title+21%E2%80%94Food+and+drugs%3A+Chapter+i%E2%80%94Food+and+drug+administration%3A+Department+of+health+and+human+services%3A+Subchapter+H%E2%80%94Medical+devices%3A+Part+860+Medical+device+classification+procedures&rft_id=http%3A%2F%2Fwww.accessdata.fda.gov%2Fscripts%2Fcdrh%2Fcfdocs%2FcfCFR%2FCFRSearch.cfm%3FCFRPart%3D860&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-Zuckerman_2011-15\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-Zuckerman_2011_15-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-Zuckerman_2011_15-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite id=\"rdp-ebb-CITEREFZuckerman2011\" class=\"citation\">Zuckerman, Diana (2011), <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/archinte.jamanetwork.com\/article.aspx?articleid=227466\" target=\"_blank\">\"Medical Device Recalls and the FDA Approval Process\"<\/a>, <i>Archives of Internal Medicine<\/i>, <b>171<\/b> (11): 1006\u201311, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1001%2Farchinternmed.2011.30\" target=\"_blank\">10.1001\/archinternmed.2011.30<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" class=\"mw-redirect\" title=\"PubMed Identifier\" rel=\"external_link\" target=\"_blank\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.ncbi.nlm.nih.gov\/pubmed\/21321283\" target=\"_blank\">21321283<\/a><\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Archives+of+Internal+Medicine&rft.atitle=Medical+Device+Recalls+and+the+FDA+Approval+Process&rft.volume=171&rft.issue=11&rft.pages=1006-11&rft.date=2011&rft_id=info%3Adoi%2F10.1001%2Farchinternmed.2011.30&rft_id=info%3Apmid%2F21321283&rft.aulast=Zuckerman&rft.aufirst=Diana&rft_id=http%3A%2F%2Farchinte.jamanetwork.com%2Farticle.aspx%3Farticleid%3D227466&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-controls-16\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-controls_16-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-2\" rel=\"external_link\"><sup><i><b>c<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-3\" rel=\"external_link\"><sup><i><b>d<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-4\" rel=\"external_link\"><sup><i><b>e<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-5\" rel=\"external_link\"><sup><i><b>f<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-6\" rel=\"external_link\"><sup><i><b>g<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-7\" rel=\"external_link\"><sup><i><b>h<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-8\" rel=\"external_link\"><sup><i><b>i<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-9\" rel=\"external_link\"><sup><i><b>j<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-10\" rel=\"external_link\"><sup><i><b>k<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-controls_16-11\" rel=\"external_link\"><sup><i><b>l<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/Overview\/GeneralandSpecialControls\/default.htm\" target=\"_blank\">\"General and Special Controls\"<\/a>. <i>Medical Devices<\/i>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2010-10-15<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Medical+Devices&rft.atitle=General+and+Special+Controls&rft_id=http%3A%2F%2Fwww.fda.gov%2FMedicalDevices%2FDeviceRegulationandGuidance%2FOverview%2FGeneralandSpecialControls%2Fdefault.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-general_controls-17\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-general_controls_17-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-general_controls_17-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-general_controls_17-2\" rel=\"external_link\"><sup><i><b>c<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-general_controls_17-3\" rel=\"external_link\"><sup><i><b>d<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/Overview\/GeneralandSpecialControls\/ucm055910.htm\" target=\"_blank\">\"General Controls for Medical Devices\"<\/a>. <i>Medical Devices<\/i>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2010-10-15<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Medical+Devices&rft.atitle=General+Controls+for+Medical+Devices&rft_id=http%3A%2F%2Fwww.fda.gov%2FMedicalDevices%2FDeviceRegulationandGuidance%2FOverview%2FGeneralandSpecialControls%2Fucm055910.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-18\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-18\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/web.archive.org\/web\/20140318014923\/http:\/\/www.acaom.edu\/faq-about-acupuncture\/\" target=\"_blank\">\"Frequently Asked Questions about Acupuncture\"<\/a>. American College of Acupuncture & Oriental Medicine. Archived from <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.acaom.edu\/faq-about-acupuncture\/\" target=\"_blank\">the original<\/a> on 2014-03-18.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Frequently+Asked+Questions+about+Acupuncture&rft.pub=American+College+of+Acupuncture+%26+Oriental+Medicine&rft_id=http%3A%2F%2Fwww.acaom.edu%2Ffaq-about-acupuncture%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-19\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-19\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation news\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.lexology.com\/library\/detail.aspx?g=afb9b14e-25cd-48bd-b05e-903b4860e055\" target=\"_blank\">\"BVGer-Urteil zur rechtlichen Qualifikation von Gesundheitsapps: Die App \"Sympto\" ist ein Medizinprodukt\"<\/a>. Lexology. 6 November 2018<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">13 December<\/span> 2018<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=BVGer-Urteil+zur+rechtlichen+Qualifikation+von+Gesundheitsapps%3A+Die+App+%22Sympto%22+ist+ein+Medizinprodukt&rft.date=2018-11-06&rft_id=https%3A%2F%2Fwww.lexology.com%2Flibrary%2Fdetail.aspx%3Fg%3Dafb9b14e-25cd-48bd-b05e-903b4860e055&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-20\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-20\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">TGA, Australian regulatory guidelines for medical devices (ARGMD) Version 1.1, May 2011, <a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.tga.gov.au\/pdf\/devices-argmd-01.pdf\" target=\"_blank\">http:\/\/www.tga.gov.au\/pdf\/devices-argmd-01.pdf<\/a><\/span>\n<\/li>\n<li id=\"cite_note-21\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-21\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/imed.ir\/Default.aspx?PageName=ENNews&ID=3453\" target=\"_blank\">\"Iran's Medical Devices at a glance\"<\/a>. <i>IMED.ir<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2018-11-10<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=IMED.ir&rft.atitle=Iran%27s+Medical+Devices+at+a+glance&rft_id=http%3A%2F%2Fimed.ir%2FDefault.aspx%3FPageName%3DENNews%26ID%3D3453&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-22\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-22\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">Jordan Robertson. Associated Press 8\/4\/2011<\/span>\n<\/li>\n<li id=\"cite_note-23\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-23\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Altawy, R; Youssef, A. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/ieeexplore.ieee.org\/stamp\/stamp.jsp?tp=&arnumber=7393449\" target=\"_blank\">\"Security Trade-offs in Cyber Physical Systems: A Case Study Survey on Implantable Medical Devices\"<\/a>. <i>IEEE Access<\/i>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=IEEE+Access&rft.atitle=Security+Trade-offs+in+Cyber+Physical+Systems%3A+A+Case+Study+Survey+on+Implantable+Medical+Devices&rft.au=Altawy%2C+R&rft.au=Youssef%2C+A&rft_id=http%3A%2F%2Fieeexplore.ieee.org%2Fstamp%2Fstamp.jsp%3Ftp%3D%26arnumber%3D7393449&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-24\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-24\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">New Health Hazard:Hackable Medical Implants. MSNBC.com's Technology<\/span>\n<\/li>\n<li id=\"cite_note-25\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-25\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Camara, Carmen; Peris-Lopez, Pedro; Tapiador, Juan E. (2015-06-01). \"Security and privacy issues in implantable medical devices: A comprehensive survey\". <i>Journal of Biomedical Informatics<\/i>. <b>55<\/b>: 272\u2013289. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1016%2Fj.jbi.2015.04.007\" target=\"_blank\">10.1016\/j.jbi.2015.04.007<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Serial_Number\" title=\"International Standard Serial Number\" rel=\"external_link\" target=\"_blank\">ISSN<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.worldcat.org\/issn\/1532-0480\" target=\"_blank\">1532-0480<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" class=\"mw-redirect\" title=\"PubMed Identifier\" rel=\"external_link\" target=\"_blank\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.ncbi.nlm.nih.gov\/pubmed\/25917056\" target=\"_blank\">25917056<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Biomedical+Informatics&rft.atitle=Security+and+privacy+issues+in+implantable+medical+devices%3A+A+comprehensive+survey&rft.volume=55&rft.pages=272-289&rft.date=2015-06-01&rft.issn=1532-0480&rft_id=info%3Apmid%2F25917056&rft_id=info%3Adoi%2F10.1016%2Fj.jbi.2015.04.007&rft.aulast=Camara&rft.aufirst=Carmen&rft.au=Peris-Lopez%2C+Pedro&rft.au=Tapiador%2C+Juan+E.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-26\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-26\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Pycroft, Laurie; Boccard, Sandra G.; Owen, Sarah L. F.; Stein, John F.; Fitzgerald, James J.; Green, Alexander L.; Aziz, Tipu Z. (2016-05-13). \"Brainjacking: implant security issues in invasive neuromodulation\". <i>World Neurosurgery<\/i>. <b>92<\/b>: 454\u2013462. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1016%2Fj.wneu.2016.05.010\" target=\"_blank\">10.1016\/j.wneu.2016.05.010<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Serial_Number\" title=\"International Standard Serial Number\" rel=\"external_link\" target=\"_blank\">ISSN<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.worldcat.org\/issn\/1878-8769\" target=\"_blank\">1878-8769<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" class=\"mw-redirect\" title=\"PubMed Identifier\" rel=\"external_link\" target=\"_blank\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.ncbi.nlm.nih.gov\/pubmed\/27184896\" target=\"_blank\">27184896<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=World+Neurosurgery&rft.atitle=Brainjacking%3A+implant+security+issues+in+invasive+neuromodulation&rft.volume=92&rft.pages=454-462&rft.date=2016-05-13&rft.issn=1878-8769&rft_id=info%3Apmid%2F27184896&rft_id=info%3Adoi%2F10.1016%2Fj.wneu.2016.05.010&rft.aulast=Pycroft&rft.aufirst=Laurie&rft.au=Boccard%2C+Sandra+G.&rft.au=Owen%2C+Sarah+L.+F.&rft.au=Stein%2C+John+F.&rft.au=Fitzgerald%2C+James+J.&rft.au=Green%2C+Alexander+L.&rft.au=Aziz%2C+Tipu+Z.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-27\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-27\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Takahashi, Dean (8 Aug 2008). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/venturebeat.com\/2008\/08\/08\/defcon-excuse-me-while-i-turn-off-your-pacemaker\/\" target=\"_blank\">\"Excuse Me While I turn off Your Pacemaker\"<\/a>. <i>Venture Beat<\/i>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Venture+Beat&rft.atitle=Excuse+Me+While+I+turn+off+Your+Pacemaker&rft.date=2008-08-08&rft.aulast=Takahashi&rft.aufirst=Dean&rft_id=https%3A%2F%2Fventurebeat.com%2F2008%2F08%2F08%2Fdefcon-excuse-me-while-i-turn-off-your-pacemaker%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-28\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-28\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">Hacking Medical Devices for Fun and Insulin: Breaking the Human SCADA System<\/span>\n<\/li>\n<li id=\"cite_note-29\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-29\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">Globe and Mail. Thursday Oct. 27, 2011 Jim Finkle. Insulin Pumps Vulnerable to Attacks by Hackers<\/span>\n<\/li>\n<li id=\"cite_note-ReferenceA-30\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-ReferenceA_30-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">Daily Tech June 15, 2011 Nidhi Subbaraman<\/span>\n<\/li>\n<li id=\"cite_note-31\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-31\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">Daily Tech June 15, 2011 Nidhi SubbaramanDaily Tech<\/span>\n<\/li>\n<li id=\"cite_note-32\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-32\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Becker, Rachel (27 December 2016). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.theverge.com\/2016\/12\/27\/14095166\/fda-guidance-medical-device-cybersecurity-cyberattack-hacking-guidelines\" target=\"_blank\">\"New cybersecurity guidelines for medical devices tackle evolving threats\"<\/a>. The Verge<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">29 December<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=New+cybersecurity+guidelines+for+medical+devices+tackle+evolving+threats&rft.pub=The+Verge&rft.date=2016-12-27&rft.aulast=Becker&rft.aufirst=Rachel&rft_id=https%3A%2F%2Fwww.theverge.com%2F2016%2F12%2F27%2F14095166%2Ffda-guidance-medical-device-cybersecurity-cyberattack-hacking-guidelines&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-33\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-33\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/MedicalDevices\/DeviceRegulationandGuidance\/GuidanceDocuments\/UCM482022.pdf\" target=\"_blank\">\"Postmarket Management of Cybersecurity in Medical Devices\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. 28 December 2016<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">29 December<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Postmarket+Management+of+Cybersecurity+in+Medical+Devices&rft.date=2016-12-28&rft_id=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FMedicalDevices%2FDeviceRegulationandGuidance%2FGuidanceDocuments%2FUCM482022.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-ISO11.100-34\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-ISO11.100_34-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Organization_for_Standardization\" title=\"International Organization for Standardization\" rel=\"external_link\" target=\"_blank\">International Organization for Standardization<\/a>. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.iso.org\/iso\/products\/standards\/catalogue_ics_browse.htm?ICS1=11&ICS2=100&ICS3=20&\" target=\"_blank\">\"11.100.20: Biological evaluation of medical devices\"<\/a><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">10 April<\/span> 2009<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=11.100.20%3A+Biological+evaluation+of+medical+devices&rft.au=International+Organization+for+Standardization&rft_id=http%3A%2F%2Fwww.iso.org%2Fiso%2Fproducts%2Fstandards%2Fcatalogue_ics_browse.htm%3FICS1%3D11%26ICS2%3D100%26ICS3%3D20%26&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-meg-35\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-meg_35-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Organization_for_Standardization\" title=\"International Organization for Standardization\" rel=\"external_link\" target=\"_blank\">International Organization for Standardization<\/a>. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.iso.org\/iso\/iso_catalogue\/catalogue_ics\/catalogue_ics_browse.htm?ICS1=11&ICS2=040\" target=\"_blank\">\"11.040: Medical equipment\"<\/a><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2009<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=11.040%3A+Medical+equipment&rft.au=International+Organization+for+Standardization&rft_id=http%3A%2F%2Fwww.iso.org%2Fiso%2Fiso_catalogue%2Fcatalogue_ics%2Fcatalogue_ics_browse.htm%3FICS1%3D11%26ICS2%3D040&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-36\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-36\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.iso.org\/iso\/catalogue_detail?csnumber=36786\" target=\"_blank\">\"ISO 13485:2003 - Medical devices -- Quality management systems -- Requirements for regulatory purposes\"<\/a>. <i>www.iso.org<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">27 March<\/span> 2018<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=www.iso.org&rft.atitle=ISO+13485%3A2003+-+Medical+devices+--+Quality+management+systems+--+Requirements+for+regulatory+purposes&rft_id=http%3A%2F%2Fwww.iso.org%2Fiso%2Fcatalogue_detail%3Fcsnumber%3D36786&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-37\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-37\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Canada, Health. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.hc-sc.gc.ca\/dhp-mps\/md-im\/qualsys\/index-eng.php\" target=\"_blank\">\"Quality Systems ISO 13485 - Canada.ca\"<\/a>. <i>www.hc-sc.gc.ca<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">27 March<\/span> 2018<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=www.hc-sc.gc.ca&rft.atitle=Quality+Systems+ISO+13485+-+Canada.ca&rft.aulast=Canada&rft.aufirst=Health&rft_id=http%3A%2F%2Fwww.hc-sc.gc.ca%2Fdhp-mps%2Fmd-im%2Fqualsys%2Findex-eng.php&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-38\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-38\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/MedicalDevices\/DeviceRegulationandGuidance\/PostmarketRequirements\/QualitySystemsRegulations\/UCM134625.pdf\" target=\"_blank\">\"ISO 13485 in USA\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. <i>fda.gov<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">27 March<\/span> 2018<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=fda.gov&rft.atitle=ISO+13485+in+USA&rft_id=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FMedicalDevices%2FDeviceRegulationandGuidance%2FPostmarketRequirements%2FQualitySystemsRegulations%2FUCM134625.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-39\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-39\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.mkprecision.com\/wp-content\/uploads\/ISO-Standards-Applied-to-Medical-Device-Manufacturing.pdf\" target=\"_blank\">\"ISO Standards Applied to Medical Device Manufacturing\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. MK Precision<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">27 October<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=ISO+Standards+Applied+to+Medical+Device+Manufacturing&rft.pub=MK+Precision&rft_id=http%3A%2F%2Fwww.mkprecision.com%2Fwp-content%2Fuploads%2FISO-Standards-Applied-to-Medical-Device-Manufacturing.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-dp-40\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-dp_40-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">Food and Drug Administration <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/Standards\/default.htm\" target=\"_blank\">Standards (Medical Devices)<\/a> Page Last Updated: 11 March 2014. Accessed 18 May 2014<\/span>\n<\/li>\n<li id=\"cite_note-41\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-41\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/blog.spartasystems.com\/feed\/preparing-your-complaintsemdr-system-for-upcoming-fda-mandate\" target=\"_blank\">\"Preparing a Complaints\/eMDR System for Upcoming FDA Mandate\"<\/a>. Sparta Systems. 18 May 2015.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Preparing+a+Complaints%2FeMDR+System+for+Upcoming+FDA+Mandate&rft.pub=Sparta+Systems&rft.date=2015-05-18&rft_id=http%3A%2F%2Fblog.spartasystems.com%2Ffeed%2Fpreparing-your-complaintsemdr-system-for-upcoming-fda-mandate&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-42\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-42\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/computingcases.org\/case_materials\/therac\/supporting_docs\/therac_resources\/Timeline.html\" target=\"_blank\">\"Therac-25 Timeline\"<\/a>. Computingcases.org<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2011-01-04<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Therac-25+Timeline&rft.pub=Computingcases.org&rft_id=http%3A%2F%2Fcomputingcases.org%2Fcase_materials%2Ftherac%2Fsupporting_docs%2Ftherac_resources%2FTimeline.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-43\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-43\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Jones, Paul; Jetley, Raoul; Abraham, Jay (2010-02-09). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.embedded.com\/design\/prototyping-and-development\/4008888\/A-Formal-Methods-based-verification-approach-to-medical-device-software-analysis\" target=\"_blank\">\"A Formal Methods-based verification approach to medical device software analysis\"<\/a>. Embedded Systems Design<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2016-04-21<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=A+Formal+Methods-based+verification+approach+to+medical+device+software+analysis&rft.pub=Embedded+Systems+Design&rft.date=2010-02-09&rft.aulast=Jones&rft.aufirst=Paul&rft.au=Jetley%2C+Raoul&rft.au=Abraham%2C+Jay&rft_id=http%3A%2F%2Fwww.embedded.com%2Fdesign%2Fprototyping-and-development%2F4008888%2FA-Formal-Methods-based-verification-approach-to-medical-device-software-analysis&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-44\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-44\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">FDA (2010-09-08). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/ProductsandMedicalProcedures\/GeneralHospitalDevicesandSupplies\/InfusionPumps\/ucm202511.htm\" target=\"_blank\">\"Infusion Pump Software Safety Research at FDA\"<\/a>. FDA<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2010-09-09<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Infusion+Pump+Software+Safety+Research+at+FDA&rft.pub=FDA&rft.date=2010-09-08&rft.au=FDA&rft_id=http%3A%2F%2Fwww.fda.gov%2FMedicalDevices%2FProductsandMedicalProcedures%2FGeneralHospitalDevicesandSupplies%2FInfusionPumps%2Fucm202511.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-trautman2015-45\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-trautman2015_45-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Trautman, Kim (16 January 2015). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/blogs.fda.gov\/fdavoice\/index.php\/2015\/01\/australia-brazil-canada-japan-and-the-us-safeguarding-medical-devices\/\" target=\"_blank\">\"Australia, Brazil, Canada, Japan, and the US: Safeguarding Medical Devices\"<\/a>. <i><\/i>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/USFDA\" class=\"mw-redirect\" title=\"USFDA\" rel=\"external_link\" target=\"_blank\">Food and Drug Administration<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=FDA+Voice&rft.atitle=Australia%2C+Brazil%2C+Canada%2C+Japan%2C+and+the+US%3A+Safeguarding+Medical+Devices&rft.date=2015-01-16&rft.au=Trautman%2C+Kim&rft_id=http%3A%2F%2Fblogs.fda.gov%2Ffdavoice%2Findex.php%2F2015%2F01%2Faustralia-brazil-canada-japan-and-the-us-safeguarding-medical-devices%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-46\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-46\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Lenzer, Jeanne (2018-11-27). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.bmj.com\/content\/363\/bmj.k5026\" target=\"_blank\">\"FDA recommends \"modernizing\" review of devices in wake of global investigation\"<\/a>. <i>BMJ<\/i>. <b>363<\/b>: k5026. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1136%2Fbmj.k5026\" target=\"_blank\">10.1136\/bmj.k5026<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Serial_Number\" title=\"International Standard Serial Number\" rel=\"external_link\" target=\"_blank\">ISSN<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.worldcat.org\/issn\/1756-1833\" target=\"_blank\">1756-1833<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" class=\"mw-redirect\" title=\"PubMed Identifier\" rel=\"external_link\" target=\"_blank\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.ncbi.nlm.nih.gov\/pubmed\/30482750\" target=\"_blank\">30482750<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=BMJ&rft.atitle=FDA+recommends+%22modernizing%22+review+of+devices+in+wake+of+global+investigation&rft.volume=363&rft.pages=k5026&rft.date=2018-11-27&rft.issn=1756-1833&rft_id=info%3Apmid%2F30482750&rft_id=info%3Adoi%2F10.1136%2Fbmj.k5026&rft.aulast=Lenzer&rft.aufirst=Jeanne&rft_id=https%3A%2F%2Fwww.bmj.com%2Fcontent%2F363%2Fbmj.k5026&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-47\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-47\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Coombes, Rebecca (2018-11-26). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.bmj.com\/content\/363\/bmj.k5010\" target=\"_blank\">\"Surgeons call for compulsory registers of all new medical devices\"<\/a>. <i>BMJ<\/i>. <b>363<\/b>: k5010. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1136%2Fbmj.k5010\" target=\"_blank\">10.1136\/bmj.k5010<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Serial_Number\" title=\"International Standard Serial Number\" rel=\"external_link\" target=\"_blank\">ISSN<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.worldcat.org\/issn\/1756-1833\" target=\"_blank\">1756-1833<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" class=\"mw-redirect\" title=\"PubMed Identifier\" rel=\"external_link\" target=\"_blank\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.ncbi.nlm.nih.gov\/pubmed\/30478186\" target=\"_blank\">30478186<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=BMJ&rft.atitle=Surgeons+call+for+compulsory+registers+of+all+new+medical+devices&rft.volume=363&rft.pages=k5010&rft.date=2018-11-26&rft.issn=1756-1833&rft_id=info%3Apmid%2F30478186&rft_id=info%3Adoi%2F10.1136%2Fbmj.k5010&rft.aulast=Coombes&rft.aufirst=Rebecca&rft_id=https%3A%2F%2Fwww.bmj.com%2Fcontent%2F363%2Fbmj.k5010&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-48\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-48\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite id=\"rdp-ebb-CITEREFDacy2010\" class=\"citation\">Dacy, D (2010), <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.mddionline.com\/article\/optimizing-package-design-eto-sterilization\" target=\"_blank\">\"Optimizing Package Design for EtO Sterilization\"<\/a>, <i>Medical Device and Diagnostic Industry<\/i>, <b>33<\/b> (1)<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Medical+Device+and+Diagnostic+Industry&rft.atitle=Optimizing+Package+Design+for+EtO+Sterilization&rft.volume=33&rft.issue=1&rft.date=2010&rft.aulast=Dacy&rft.aufirst=D&rft_id=http%3A%2F%2Fwww.mddionline.com%2Farticle%2Foptimizing-package-design-eto-sterilization&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-49\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-49\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.astm.org\/SNEWS\/SO_2009\/enright2_so09.html\" target=\"_blank\">\"ASTM International - Standards Worldwide\"<\/a>. <i>www.astm.org<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2017-08-23<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=www.astm.org&rft.atitle=ASTM+International+-+Standards+Worldwide&rft_id=https%3A%2F%2Fwww.astm.org%2FSNEWS%2FSO_2009%2Fenright2_so09.html&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-50\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-50\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">\n<cite id=\"rdp-ebb-CITEREFBix,_L.Fuente,_J.2009\" class=\"citation\">Bix, L.; Fuente, J. (2009), \"Medical Device Packaging\", in Yam, K. L, <i>Wiley Encyclopedia of Packaging Technology<\/i>, Wiley, <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 978-0-470-08704-6<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Medical+Device+Packaging&rft.btitle=Wiley+Encyclopedia+of+Packaging+Technology&rft.pub=Wiley&rft.date=2009&rft.isbn=978-0-470-08704-6&rft.au=Bix%2C+L.&rft.au=Fuente%2C+J.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-51\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-51\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\">\n<cite id=\"rdp-ebb-CITEREFFotis,_N.Bix,_L.2006\" class=\"citation\">Fotis, N.; Bix, L. (2006), <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.mddionline.com\/article\/sample-size-selection-using-margin-error-approach\" target=\"_blank\">\"Sample Size Selection Using Margin of Error Approach\"<\/a>, <i>Medical Device and Diagnostic Industry<\/i>, <b>28<\/b> (10): 80\u201389<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Medical+Device+and+Diagnostic+Industry&rft.atitle=Sample+Size+Selection+Using+Margin+of+Error+Approach&rft.volume=28&rft.issue=10&rft.pages=80-89&rft.date=2006&rft.au=Fotis%2C+N.&rft.au=Bix%2C+L.&rft_id=http%3A%2F%2Fwww.mddionline.com%2Farticle%2Fsample-size-selection-using-margin-error-approach&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-52\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-52\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/ors.org\/Transactions\/49\/1346.pdf\" target=\"_blank\">\"Spiegelberg, S.H., Deluzio, K.J., Muratoglu, O.K., \"Extractable residue from recalled Inter-Op acetabular shells,\" 49th Annual Meeting of the Orthopaedic Research Society, 2003\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. <i>ors.org<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">27 March<\/span> 2018<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=ors.org&rft.atitle=Spiegelberg%2C+S.H.%2C+Deluzio%2C+K.J.%2C+Muratoglu%2C+O.K.%2C+%22Extractable+residue+from+recalled+Inter-Op+acetabular+shells%2C%22+49th+Annual+Meeting+of+the+Orthopaedic+Research+Society%2C+2003&rft_id=http%3A%2F%2Fors.org%2FTransactions%2F49%2F1346.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-53\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-53\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.astm.org\/Standards\/F2459.htm\" target=\"_blank\">\"Standard Test Method for Extracting Residue from Metallic Medical Components and Quantifying via Gravimetric Analysis\"<\/a>. <i>ASTM International Products and Services<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=ASTM+International+Products+and+Services&rft.atitle=Standard+Test+Method+for+Extracting+Residue+from+Metallic+Medical+Components+and+Quantifying+via+Gravimetric+Analysis&rft_id=http%3A%2F%2Fwww.astm.org%2FStandards%2FF2459.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-54\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-54\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.astm.org\/Standards\/F2847.htm\" target=\"_blank\">\"Standard Practice for Reporting and Assessment of Residues on Single Use Implants\"<\/a>. <i>ASTM Products and Services<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=ASTM+Products+and+Services&rft.atitle=Standard+Practice+for+Reporting+and+Assessment+of+Residues+on+Single+Use+Implants&rft_id=http%3A%2F%2Fwww.astm.org%2FStandards%2FF2847.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-astm.org-55\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-astm.org_55-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-astm.org_55-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.astm.org\/Standards\/F3208.htm\" target=\"_blank\">\"ASTM F3208 - 17 Standard Guide for Selecting Test Soils for Validation of Cleaning Methods for Reusable Medical Devices\"<\/a>. <i>www.astm.org<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">27 March<\/span> 2018<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=www.astm.org&rft.atitle=ASTM+F3208+-+17+Standard+Guide+for+Selecting+Test+Soils+for+Validation+of+Cleaning+Methods+for++Reusable+Medical+Devices&rft_id=https%3A%2F%2Fwww.astm.org%2FStandards%2FF3208.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-56\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-56\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.astm.org\/Standards\/E2314.htm\" target=\"_blank\">\"Standard Test Method for Determination of Effectiveness of Cleaning Processes for Reusable Medical Instruments Using a Microbiologic Method (Simulated Use Test)\"<\/a>. <i>ASTM International - Products and Services<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=ASTM+International+-+Products+and+Services&rft.atitle=Standard+Test+Method+for+Determination+of+Effectiveness+of+Cleaning+Processes+for+Reusable+Medical+Instruments+Using+a+Microbiologic+Method+%28Simulated+Use+Test%29&rft_id=http%3A%2F%2Fwww.astm.org%2FStandards%2FE2314.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-57\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-57\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.astm.org\/Standards\/D7225.htm\" target=\"_blank\">\"Standard Guide for Blood Cleaning Efficiency of Detergents and Washer-Disinfectors\"<\/a>. 2014<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Standard+Guide+for+Blood+Cleaning+Efficiency+of+Detergents+and+Washer-Disinfectors&rft.date=2014&rft_id=http%3A%2F%2Fwww.astm.org%2FStandards%2FD7225.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-58\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-58\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.astm.org\/COMMITTEE\/F04.htm\" target=\"_blank\">\"Committee F04 on Medical and Surgical Materials and Devices\"<\/a>. 2014<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Committee+F04+on+Medical+and+Surgical+Materials+and+Devices&rft.date=2014&rft_id=http%3A%2F%2Fwww.astm.org%2FCOMMITTEE%2FF04.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-59\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-59\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/ReprocessingofReusableMedicalDevices\/default.htm\" target=\"_blank\">\"Reprocessing of Reusable Medical Devices\"<\/a>. <i>U.S. Department of Health and Human Services - Food and Drug Administration - Medical Devices<\/i>. 2014<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">15 June<\/span> 2014<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=U.S.+Department+of+Health+and+Human+Services+-+Food+and+Drug+Administration+-+Medical+Devices&rft.atitle=Reprocessing+of+Reusable+Medical+Devices&rft.date=2014&rft_id=http%3A%2F%2Fwww.fda.gov%2FMedicalDevices%2FDeviceRegulationandGuidance%2FReprocessingofReusableMedicalDevices%2Fdefault.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-60\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-60\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><a rel=\"external_link\" class=\"external free\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/ProductsandMedicalProcedures\/ConnectedHealth\/MobileMedicalApplications\/ucm255978.htm\" target=\"_blank\">http:\/\/www.fda.gov\/MedicalDevices\/ProductsandMedicalProcedures\/ConnectedHealth\/MobileMedicalApplications\/ucm255978.htm<\/a><\/span>\n<\/li>\n<li id=\"cite_note-61\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-61\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Yetisen A. K.; Martinez-Hurtado J. L.; et al. (2014). \"The regulation of mobile medical applications\". <i>Lab on a Chip<\/i>. <b>14<\/b> (5): 833\u2013840. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1039%2FC3LC51235E\" target=\"_blank\">10.1039\/C3LC51235E<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Lab+on+a+Chip&rft.atitle=The+regulation+of+mobile+medical+applications&rft.volume=14&rft.issue=5&rft.pages=833-840&rft.date=2014&rft_id=info%3Adoi%2F10.1039%2FC3LC51235E&rft.au=Yetisen+A.+K.&rft.au=Martinez-Hurtado+J.+L.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-62\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-62\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Vincent, Christopher James; Niezen, Gerrit; O'Kane, Aisling Ann; Stawarz, Katarzyna (3 June 2015). \"Can Standards and Regulations Keep Up With Health Technology?\". <i>JMIR mHealth and uHealth<\/i>. <b>3<\/b> (2): e64. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.2196%2Fmhealth.3918\" target=\"_blank\">10.2196\/mhealth.3918<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=JMIR+mHealth+and+uHealth&rft.atitle=Can+Standards+and+Regulations+Keep+Up+With+Health+Technology%3F&rft.volume=3&rft.issue=2&rft.pages=e64&rft.date=2015-06-03&rft_id=info%3Adoi%2F10.2196%2Fmhealth.3918&rft.aulast=Vincent&rft.aufirst=Christopher+James&rft.au=Niezen%2C+Gerrit&rft.au=O%27Kane%2C+Aisling+Ann&rft.au=Stawarz%2C+Katarzyna&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-jce-63\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-jce_63-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/Lippincott_Williams_%26_Wilkins\" title=\"Lippincott Williams & Wilkins\" rel=\"external_link\" target=\"_blank\">Lippincott Williams & Wilkins<\/a>. <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/pt.wkhealth.com\/pt\/re\/jce\/home.htm;jsessionid=JpYXfLlnQ8TLpH1QhcM0T2HSpsQLFJLTSBcHHmC0QjzGgpPJ9V9Q!-707522149!181195629!8091!-1\" target=\"_blank\">\"Journal Information\"<\/a><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">10 April<\/span> 2009<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Journal+Information&rft.au=Lippincott+Williams+%26+Wilkins&rft_id=http%3A%2F%2Fpt.wkhealth.com%2Fpt%2Fre%2Fjce%2Fhome.htm%3Bjsessionid%3DJpYXfLlnQ8TLpH1QhcM0T2HSpsQLFJLTSBcHHmC0QjzGgpPJ9V9Q%21-707522149%21181195629%218091%21-1&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-64\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-64\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.canr.msu.edu\/packaging\/\" target=\"_blank\">\"School of Packaging\"<\/a>. <i>School of Packaging<\/i><span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">2017-08-23<\/span><\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=School+of+Packaging&rft.atitle=School+of+Packaging&rft_id=http%3A%2F%2Fwww.canr.msu.edu%2Fpackaging%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+device\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<\/ol><\/div>\n<h2><span class=\"mw-headline\" id=\"External_links\">External links<\/span><\/h2>\n<ul><li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/Training\/CDRHLearn\/\" target=\"_blank\">US Food and Drug Administration \u2013 Center for Devices and Radiological Health<\/a>\n<ul><li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/HowtoMarketYourDevice\/PremarketSubmissions\/PremarketNotification510k\/default.htm\" target=\"_blank\">Premarket Notification (510k)<\/a><\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/MedicalDevices\/DeviceRegulationandGuidance\/HowtoMarketYourDevice\/PremarketSubmissions\/PremarketApprovalPMA\/ucm2007514.htm\" target=\"_blank\">Premarket Approval (PMA)<\/a><\/li><\/ul><\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/medicaldevices\/deviceregulationandguidance\/overview\/classifyyourdevice\/ucm051512.htm\" target=\"_blank\">FDA \u2013 Is the Product a Medical Device?<\/a><\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.gov.uk\/topic\/medicines-medical-devices-blood\/medical-devices-regulation-safety\" target=\"_blank\">MHRA - Medical devices regulation and safety<\/a><\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/ec.europa.eu\/growth\/single-market\/european-standards\/harmonised-standards\/medical-devices\/index_en.htm\" target=\"_blank\">EC - Medical devices<\/a><\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.hc-sc.gc.ca\/dhp-mps\/md-im\/standards-normes\/md_rec_stand_im_norm_lst-eng.php\" target=\"_blank\">Health Canada - List of Recognized Standards for Medical Devices<\/a> (International)<\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.iso.org\/iso\/products\/standards\/catalogue_ics_browse.htm?ICS1=11&ICS2=040&ICS3=01&\" target=\"_blank\">ISO - Standards catalogue: 11.040.01: Medical equipment in general<\/a><\/li>\n<li><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.fda.gov\/RegulatoryInformation\/Guidances\/ucm077210.htm\" target=\"_blank\">Radio Frequency Wireless Technology in Medical Devices - Guidance for Industry and Food and Drug Administration Staff<\/a>. FDA (2013)<\/li><\/ul>\n<p><!-- \nNewPP limit report\nParsed by mw1254\nCached time: 20190102141921\nCache expiry: 1900800\nDynamic content: false\nCPU time usage: 0.752 seconds\nReal time usage: 0.930 seconds\nPreprocessor visited node count: 3838\/1000000\nPreprocessor generated node count: 0\/1500000\nPost\u2010expand include size: 93201\/2097152 bytes\nTemplate argument size: 2640\/2097152 bytes\nHighest expansion depth: 7\/40\nExpensive parser function count: 2\/500\nUnstrip recursion depth: 1\/20\nUnstrip post\u2010expand size: 150582\/5000000 bytes\nNumber of Wikibase entities loaded: 2\/400\nLua time usage: 0.436\/10.000 seconds\nLua memory usage: 5.14 MB\/50 MB\n-->\n<!--\nTransclusion expansion time report (%,ms,calls,template)\n100.00% 792.067 1 -total\n<\/p>\n<pre>55.81% 442.075 1 Template:Reflist\n32.16% 254.730 40 Template:Cite_web\n26.77% 212.009 23 Template:Annotated_link\n24.89% 197.180 49 Template:Template_parameter_value\n 7.78% 61.645 7 Template:Cite_journal\n 6.00% 47.505 4 Template:Citation\n 5.41% 42.854 1 Template:Short_description\n 4.90% 38.831 1 Template:Pagetype\n 1.55% 12.309 1 Template:Div_col\n<\/pre>\n<p>-->\n<\/p><p><!-- Saved in parser cache with key enwiki:pcache:idhash:1363291-1!canonical and timestamp 20190102141920 and revision id 875961440\n<\/p>\n<pre>-->\n<\/pre>\n<\/div>\n<h2><span class=\"mw-headline\" id=\"Notes\">Notes<\/span><\/h2>\n<p>This article is a direct transclusion of <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_device\" target=\"_blank\">the Wikipedia article<\/a> and therefore may not meet the same editing standards as LIMSwiki.\n<\/p>\n<!-- \nNewPP limit report\nCached time: 20190104224851\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.027 seconds\nReal time usage: 0.143 seconds\nPreprocessor visited node count: 5\/1000000\nPreprocessor generated node count: 20\/1000000\nPost\u2010expand include size: 20\/2097152 bytes\nTemplate argument size: 0\/2097152 bytes\nHighest expansion depth: 2\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 126.310 1 - wikipedia:Medical_device\n100.00% 126.310 1 - -total\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:7959-0!*!*!*!*!*!* and timestamp 20190104224851 and revision id 24076\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/Medical_device\">https:\/\/www.limswiki.org\/index.php\/Medical_device<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","8e821122daa731f0fa8782fae57831fa_images":["https:\/\/upload.wikimedia.org\/wikipedia\/commons\/b\/bf\/Stetoskop.jpg"],"8e821122daa731f0fa8782fae57831fa_timestamp":1546642130,"79dbc75d9223c22375492817dbae2161_type":"article","79dbc75d9223c22375492817dbae2161_title":"Medical software","79dbc75d9223c22375492817dbae2161_url":"https:\/\/www.limswiki.org\/index.php\/Medical_software","79dbc75d9223c22375492817dbae2161_plaintext":"\n\n\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\n\n\t\t\t\tMedical software\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t\tFrom LIMSWiki\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\tJump to: navigation, search\n\n\t\t\t\t\t\n\t\t\t\t\tMedical software is any software item or system used within a medical context, such as:[1][2][3]\n\nstandalone software used for diagnostic or therapeutic purposes;\nsoftware embedded in a medical device (often referred to as \"medical device software\");\nsoftware that drives a medical device or determines how it is used;\nsoftware that acts as an accessory to a medical device;\nsoftware used in the design, production, and testing of a medical device; or\nsoftware that provides quality control management of a medical device.\nContents \n\n1 History \n2 Medical device software \n\n2.1 Software as a medical device \n\n\n3 International standards \n4 Further reading \n5 See also \n6 External links \n7 References \n\n\nHistory \nMedical software has been in use since at least since the 1960s,[4] a time when the first computerized information-handling system in the hospital sphere was being considered by Lockheed.[5][6] As computing became more widespread and useful in the late 1970s and into the 1980s, the concept of \"medical software\" as a data and operations management tool in the medical industry \u2014 including in the physician's office \u2014 became more prevalent.[7][8] Medical software became more prominent in medical devices in fields such as nuclear medicine, cardiology, and medical robotics by the early 1990s, prompting additional scrutiny of the \"safety-critical\" nature of medical software in the research and legislative communities, in part fueled by the Therac-25 radiation therapy device scandal.[9][10] The development of the ISO 9000-3 standard[9] as well as the European Medical Devices Directive in 1993[1] helped bring some harmonization of existing laws with medical devices and their associated software, and the addition of IEC 62304 in 2006 further cemented how medical device software should be developed and tested.[11] The U.S. Food and Drug Administration (FDA) has also offered guidance and driven regulation on medical software, particularly embedded in and used as medical devices.[2][12][13]\n\n A portable heart rate variability device is an example of a medical device that contains medical device software.\nMedical device software \nThe global IEC 62304 standard on the software life cycle processes of medical device software states it's a \"software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right.\"[11] In the U.S., the FDA states that \"any software that meets the legal definition of a [medical] device\" is considered medical device software.[14] A similar \"software can be a medical device\" interpretation was also made by the European Union in 2007 with an update to its European Medical Devices Directive, when \"used specifically for diagnostic and\/or therapeutic purposes.\"[15]\nDue to the broad scope covered by these terms, manifold classifications can be proposed for various medical software, based for instance on their technical nature (embedded in a device or standalone), on their level of safety (from the most trivial to the most safety-critical ones), or on their primarily function (treatment, education, diagnostics, and\/or data management).\n\nSoftware as a medical device \nThe dramatic increase in smartphone usage in the twenty-first century triggered the emergence of thousands of stand-alone health- and medical-related software apps, many falling into a gray or borderline area in terms of regulation. While software embedded into a medical device was being addressed, medical software separate from medical hardware \u2014 referred to by the International Medical Device Regulators Forum (IMDRF) as \"software as a medical device\" or \"SaMD\"[16] \u2014 was falling through existing regulatory cracks. In the U.S., the FDA eventually released new draft guidance in July 2011 on \"mobile medical applications,\" with members of the legal community such as Keith Barritt speculating it should be read to imply \"as applicable to all software ... since the test for determining whether a mobile application is a regulated mobile 'medical' application is the same test one would use to determine if any software is regulated.\"[17] Examples of mobile apps potentially covered by the guidance included those that regulate an installed pacemaker or those that analyze images for cancerous lesions, X-rays and MRI, graphic data such as EEG waveforms as well as bedside monitors, urine analyzers, glucometer, stethoscopes, spirometers, BMI calculators, heart rate monitors and body fat calculators.[18] By the time its final guidance was released in late 2013, however, members of Congress began to be concerned about the how the guidance would be used in the future, in particular with what it would mean to the SOFTWARE Act legislation that had recently been introduced.[19] Around the same time, the IMDRF were working on a more global perspective of SaMD with the release of its Key Definitions in December 2013, focused on \"[establishing] a common framework for regulators to incorporate converged controls into their regulatory approaches for SaMD.\"[16] Aside from \"not [being] necessary for a hardware medical device to achieve its intended medical purpose,\" the IMDRF also found that SaMD also couldn't drive a medical device, though it could be used as a module of or interfaced with one.[16] The group further developed quality management system principles for SaMD in 2015.[20]\n\nInternational standards \nIEC 62304 has become the benchmark standard for the development of medical device software, whether standalone software or otherwise, in both the E.U. and the U.S.[3][21] Leading industry innovation in software technologies has led key industry leaders and government regulators to recognize the emergence of numerous standalone medical software products that operate as medical devices. This has been reflected in regulatory changes in the E.U. (European Medical Devices Directive[1]) and the U.S. (various FDA guidance documents[2][12][13][19]). Additionally, quality management system requirements for manufacturing a software medical device, as is the case with any medical device, are described in the U.S. Quality Systems Regulation[22] of the FDA and also in ISO 13485:2003. Software technology manufacturers that operate within the software medical device space conduct mandatory development of their products in accordance with those requirements. Furthermore, though not mandatory, they may elect to obtain certification from a notified body, having implemented such quality system requirements as described within international standards such as ISO 13485:2003.\n\nFurther reading \nBecchetti, C.; Neri, A. (2013). \"Chapter 6: Medical Software\". Medical Instrument Design and Development: From Requirements to Market Placements. Chichester, U.K.: John Wiley & Sons Ltd. pp. 359\u2013418. ISBN 9781119952404. \nDegoulet, P.; Fieschi, M. (2012). \"Chapter 2: Medical Software Development\". Introduction to Clinical Informatics. New York: Springer Science & Business Media. pp. 19\u201334. ISBN 9781461268659. \nSee also \nHealth informatics\nHealth information technology\nCategory:Medical software\nExternal links \n Media related to Medical Software at Wikimedia Commons\n\nReferences \n\n\n^ a b c Becchetti, C.; Neri, A. (2013). \"Chapter 6: Medical Software\". Medical Instrument Design and Development: From Requirements to Market Placements. Chichester, U.K.: John Wiley & Sons Ltd. pp. 359\u2013418. ISBN 9781119952404. \n\n^ a b c Vogel, D.A. (2011). \"Chapter 3: The FDA Software Validation Regulations and Why You Should Validate Software Anyway\". Medical Device Software Verification, Validation, and Compliance. Boston, MA: Artech House. pp. 27\u201336. ISBN 9781596934238. \n\n^ a b Jetley, R.; Sudarsan, S.; R., Sampath; Ramaswamy, S. (2013). \"Medical Software - Issues and Best Practices\". Distributed Computing and Internet Technology: 9th International Conference, ICDCIT 2013, Bhubaneswar, India, February 5-8, 2013, Proceedings. Hyderabad, India: Springer. pp. 69\u201391. ISBN 9783642360718. \n\n^ \"Radar and Electronics\". Radar and Electronics Association. March 1963. Retrieved 26 April 2016 . \n\n^ Lockheed Hospital Information System. Lockheed Aircraft Corporation. 1965. p. 82. \n\n^ Gall, John E.; Norwood, Donald D.; El Camino Hospital (1977). Demonstration and evaluation of a total hospital information system. NCHSR research summary series. U.S. Dept. of Health, Education, and Welfare, Public Health Service, Health Resources Administration, National Center for Health Services Research. p. 38. \n\n^ Zimmerman, J.; Rector, A. (1978). Computers for the Physician's Office. Forest Grove, OR: Research Studies Press. p. 305. ISBN 0893550078. \n\n^ Freedman, E.; Hecht, E.; Whiteside, D. (1985). \"Consultants Perspective on Medical Office Computerization\". Computers in Healthcare, Volume 6. Englewood: Cardiff Publishing Company. \n\n^ a b Cosgriff, P.S. (1994). \"Quality assurance of medical software\". Journal of Medical Engineering & Technology. 18 (1): 1\u201310. doi:10.3109\/03091909409030782. PMID 8006924. \n\n^ Jones, P.; Jetley, R.; Abraham, J. (9 February 2010). \"A Formal Methods-based verification approach to medical device software analysis\". Embedded. UBM. Retrieved 26 April 2016 . \n\n^ a b International Electrotechnical Commission (2006). \"Medical device software \u2013 Software life cycle processes\" (PDF) . International Standard IEC 62304, First Edition 2006-05. International Electrotechnical Commission. Retrieved 26 April 2016 . \n\n^ a b Office of Device Evaluation, Center for Devices and Radiological Health (9 September 1999). \"Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices\" (PDF) . U.S. Food and Drug Administration. Retrieved 26 April 2016 . \n\n^ a b Center for Devices; Radiological Health (11 May 2005). \"Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices\". U.S. Food and Drug Administration. Retrieved 26 April 2016 . \n\n^ Murray Jr., J.F. (March 2010). \"CDRH Regulated Software: An Introduction\" (PDF) . U.S. Food and Drug Administration. Retrieved 26 April 2016 . \n\n^ \"Directive 2007\/47\/ED of the European Parliament and of the Council\" (PDF) . Official Journal of the European Union. European Union. 5 September 2007. Retrieved 26 April 2016 . \n\n^ a b c Spanou, D. (9 December 2013). \"Software as a Medical Device (SaMD): Key Definitions\" (PDF) . International Medical Device Regulators Forum. p. 9. Retrieved 26 April 2016 . \n\n^ \"New FDA Draft Guidance Sheds Light On Regulation of 'Mobile Medical Apps' and Other Software\" (PDF) . Medical Devices Law & Industry Report. 5 (16): 1\u20133. August 2011. Retrieved 26 April 2016 . \n\n^ Yetisen, A.K.; Martinez-Hurtado, J.L.; Vasconcellos, F.C.; Simsekler, M.C.E.; Akram, M.S.; Lowe, C.R. (2014). \"The regulation of mobile medical applications\". Lab on a Chip. 14 (5): 833\u2013840. doi:10.1039\/C3LC51235E. \n\n^ a b Slabodkin, G. (20 November 2013). \"Congress, FDA at odds over software as a medical device\". Fierce Mobile Healthcare. Questex, LLC. \n\n^ Mezher, M. (8 April 2015). \"IMDRF Proposes QMS Principles for Software as a Medical Device\". Regulatory Focus. Regulatory Affairs Professionals Society. Retrieved 26 April 2016 . \n\n^ Rust, P.; Flood, D.; McCaffery, F. (2015). \"Software Process Improvement and Roadmapping \u2013 A Roadmap for Implementing IEC 62304 in Organizations Developing and Maintaining Medical Device Software\". In Rout, T.; C'Connor, R.V.; Dorling, A. Software Process Improvement and Capability Determination. Cham, Switzerland: Springer. pp. 19\u201332. doi:10.1007\/978-3-319-19860-6_3. ISBN 9783319198606. \n\n^ \"Quality System (QS) Regulation\/Medical Device Good Manufacturing Practices\". U.S. Food and Drug Administration. 30 June 2014. Retrieved 26 April 2016 . \n\n\n\n\n\n<\/pre>\n\nNotes \nThis article is a direct transclusion of the Wikipedia article and therefore may not meet the same editing standards as LIMSwiki.\n\n\n\n\n\n\nSource: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/Medical_software\">https:\/\/www.limswiki.org\/index.php\/Medical_software<\/a>\n\t\t\t\t\tCategories: Health informaticsMedical softwareHidden category: Articles transcluded from other wikis\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\n\t\t\n\t\t\tNavigation menu\n\t\t\t\t\t\n\t\t\tViews\n\n\t\t\t\n\t\t\t\t\n\t\t\t\tPage\n\t\t\t\tDiscussion\n\t\t\t\tView source\n\t\t\t\tHistory\n\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\t\n\t\t\t\tPersonal tools\n\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\t\t\tLog in\n\t\t\t\t\t\t\t\t\t\t\t\t\tRequest account\n\t\t\t\t\t\t\t\t\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\n\t\t\t\t\n\t\t\t\n\t\t\t\t\n\t\tNavigation\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tMain page\n\t\t\t\t\t\t\t\t\t\t\tRecent changes\n\t\t\t\t\t\t\t\t\t\t\tRandom page\n\t\t\t\t\t\t\t\t\t\t\tHelp\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tSearch\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t \n\t\t\t\t\t\t\n\t\t\t\t\n\n\t\t\t\t\t\t\t\n\t\t\n\t\t\t\n\t\t\tTools\n\n\t\t\t\n\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tWhat links here\n\t\t\t\t\t\t\t\t\t\t\tRelated changes\n\t\t\t\t\t\t\t\t\t\t\tSpecial pages\n\t\t\t\t\t\t\t\t\t\t\tPermanent link\n\t\t\t\t\t\t\t\t\t\t\tPage information\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\tPrint\/export\n\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\tCreate a book\n\t\t\t\t\t\t\t\t\t\t\tDownload as PDF\n\t\t\t\t\t\t\t\t\t\t\tDownload as Plain text\n\t\t\t\t\t\t\t\t\t\t\tPrintable version\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\n\t\t\n\t\tSponsors\n\t\t\n\t\t\t \r\n\n\t\r\n\n\t\r\n\n\t\r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n \r\n\n\t\n\t\r\n\n\t\n\t\r\n\n\t\r\n\n\t\r\n\n\t\r\n\t\t\n\t\t\n\t\t\t\n\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\n\t\t\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t This page was last modified on 24 February 2016, at 19:47.\n\t\t\t\t\t\t\t\t\tThis page has been accessed 973 times.\n\t\t\t\t\t\t\t\t\tContent is available under a Creative Commons Attribution-ShareAlike 4.0 International License unless otherwise noted.\n\t\t\t\t\t\t\t\t\tPrivacy policy\n\t\t\t\t\t\t\t\t\tAbout LIMSWiki\n\t\t\t\t\t\t\t\t\tDisclaimers\n\t\t\t\t\t\t\t\n\t\t\n\t\t\n\t\t\n\n","79dbc75d9223c22375492817dbae2161_html":"<body class=\"mediawiki ltr sitedir-ltr ns-0 ns-subject page-Medical_software skin-monobook action-view\">\n<div id=\"rdp-ebb-globalWrapper\">\n\t\t<div id=\"rdp-ebb-column-content\">\n\t\t\t<div id=\"rdp-ebb-content\" class=\"mw-body\" role=\"main\">\n\t\t\t\t<a id=\"rdp-ebb-top\"><\/a>\n\t\t\t\t\n\t\t\t\t\n\t\t\t\t<h1 id=\"rdp-ebb-firstHeading\" class=\"firstHeading\" lang=\"en\">Medical software<\/h1>\n\t\t\t\t\n\t\t\t\t<div id=\"rdp-ebb-bodyContent\" class=\"mw-body-content\">\n\t\t\t\t\t\n\t\t\t\t\t\n\t\t\t\t\t\t\t\t\t\t\n\n\t\t\t\t\t<!-- start content -->\n\t\t\t\t\t<div id=\"rdp-ebb-mw-content-text\" lang=\"en\" dir=\"ltr\" class=\"mw-content-ltr\"><div class=\"mw-parser-output\"><p><b>Medical software<\/b> is any <a href=\"https:\/\/en.wikipedia.org\/wiki\/Software\" title=\"Software\" rel=\"external_link\" target=\"_blank\">software<\/a> item or system used within a medical context, such as:<sup id=\"rdp-ebb-cite_ref-BecchettiMed13_1-0\" class=\"reference\"><a href=\"#cite_note-BecchettiMed13-1\" rel=\"external_link\">[1]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-VogelMed11_2-0\" class=\"reference\"><a href=\"#cite_note-VogelMed11-2\" rel=\"external_link\">[2]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-JetleyMed13_3-0\" class=\"reference\"><a href=\"#cite_note-JetleyMed13-3\" rel=\"external_link\">[3]<\/a><\/sup>\n<\/p>\n<ul><li>standalone software used for <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_diagnosis\" title=\"Medical diagnosis\" rel=\"external_link\" target=\"_blank\">diagnostic<\/a> or <a href=\"https:\/\/en.wikipedia.org\/wiki\/Therapy\" title=\"Therapy\" rel=\"external_link\" target=\"_blank\">therapeutic<\/a> purposes;<\/li>\n<li>software embedded in a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_device\" title=\"Medical device\" rel=\"external_link\" target=\"_blank\">medical device<\/a> (often referred to as \"medical device software\");<\/li>\n<li>software that drives a medical device or determines how it is used;<\/li>\n<li>software that acts as an accessory to a medical device;<\/li>\n<li>software used in the design, production, and testing of a medical device; or<\/li>\n<li>software that provides quality control management of a medical device.<\/li><\/ul>\n\n<h2><span class=\"mw-headline\" id=\"History\">History<\/span><\/h2>\n<p>Medical software has been in use since at least since the 1960s,<sup id=\"rdp-ebb-cite_ref-REA63_4-0\" class=\"reference\"><a href=\"#cite_note-REA63-4\" rel=\"external_link\">[4]<\/a><\/sup> a time when the first computerized information-handling system in the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Hospital\" title=\"Hospital\" rel=\"external_link\" target=\"_blank\">hospital<\/a> sphere was being considered by <a href=\"https:\/\/en.wikipedia.org\/wiki\/Lockheed_Corporation\" title=\"Lockheed Corporation\" rel=\"external_link\" target=\"_blank\">Lockheed<\/a>.<sup id=\"rdp-ebb-cite_ref-LHHIS_5-0\" class=\"reference\"><a href=\"#cite_note-LHHIS-5\" rel=\"external_link\">[5]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-DemEvalHos_6-0\" class=\"reference\"><a href=\"#cite_note-DemEvalHos-6\" rel=\"external_link\">[6]<\/a><\/sup> As computing became more widespread and useful in the late 1970s and into the 1980s, the concept of \"medical software\" as a data and operations management tool in the medical industry \u2014 including in the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Physician%27s_office\" class=\"mw-redirect\" title=\"Physician's office\" rel=\"external_link\" target=\"_blank\">physician's office<\/a> \u2014 became more prevalent.<sup id=\"rdp-ebb-cite_ref-ZimmermanComp78_7-0\" class=\"reference\"><a href=\"#cite_note-ZimmermanComp78-7\" rel=\"external_link\">[7]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FreedmanCons85_8-0\" class=\"reference\"><a href=\"#cite_note-FreedmanCons85-8\" rel=\"external_link\">[8]<\/a><\/sup> Medical software became more prominent in medical devices in fields such as nuclear medicine, cardiology, and medical robotics by the early 1990s, prompting additional scrutiny of the \"safety-critical\" nature of medical software in the research and legislative communities, in part fueled by the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Therac-25\" title=\"Therac-25\" rel=\"external_link\" target=\"_blank\">Therac-25<\/a> radiation therapy device scandal.<sup id=\"rdp-ebb-cite_ref-CosgriffQual94_9-0\" class=\"reference\"><a href=\"#cite_note-CosgriffQual94-9\" rel=\"external_link\">[9]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-JonesAForm10_10-0\" class=\"reference\"><a href=\"#cite_note-JonesAForm10-10\" rel=\"external_link\">[10]<\/a><\/sup> The development of the ISO 9000-3 standard<sup id=\"rdp-ebb-cite_ref-CosgriffQual94_9-1\" class=\"reference\"><a href=\"#cite_note-CosgriffQual94-9\" rel=\"external_link\">[9]<\/a><\/sup> as well as the European <a href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_Devices_Directive\" title=\"Medical Devices Directive\" rel=\"external_link\" target=\"_blank\">Medical Devices Directive<\/a> in 1993<sup id=\"rdp-ebb-cite_ref-BecchettiMed13_1-1\" class=\"reference\"><a href=\"#cite_note-BecchettiMed13-1\" rel=\"external_link\">[1]<\/a><\/sup> helped bring some harmonization of existing laws with medical devices and their associated software, and the addition of <a href=\"https:\/\/en.wikipedia.org\/wiki\/IEC_62304\" title=\"IEC 62304\" rel=\"external_link\" target=\"_blank\">IEC 62304<\/a> in 2006 further cemented how medical device software should be developed and tested.<sup id=\"rdp-ebb-cite_ref-IEC62304_11-0\" class=\"reference\"><a href=\"#cite_note-IEC62304-11\" rel=\"external_link\">[11]<\/a><\/sup> The U.S. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Food_and_Drug_Administration\" title=\"Food and Drug Administration\" rel=\"external_link\" target=\"_blank\">Food and Drug Administration<\/a> (FDA) has also offered guidance and driven regulation on medical software, particularly embedded in and used as medical devices.<sup id=\"rdp-ebb-cite_ref-VogelMed11_2-1\" class=\"reference\"><a href=\"#cite_note-VogelMed11-2\" rel=\"external_link\">[2]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FDAOff99_12-0\" class=\"reference\"><a href=\"#cite_note-FDAOff99-12\" rel=\"external_link\">[12]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FDAGuidance05_13-0\" class=\"reference\"><a href=\"#cite_note-FDAGuidance05-13\" rel=\"external_link\">[13]<\/a><\/sup>\n<\/p>\n<div class=\"thumb tright\"><div class=\"thumbinner\" style=\"width:252px;\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/File:Portable_heart_rate_variability_device.JPG\" class=\"image\" rel=\"external_link\" target=\"_blank\"><img alt=\"\" src=\"https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/7\/7d\/Portable_heart_rate_variability_device.JPG\/250px-Portable_heart_rate_variability_device.JPG\" width=\"250\" height=\"375\" class=\"thumbimage\" \/><\/a> <div class=\"thumbcaption\"><div class=\"magnify\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/File:Portable_heart_rate_variability_device.JPG\" class=\"internal\" title=\"Enlarge\" rel=\"external_link\" target=\"_blank\"><\/a><\/div>A portable heart rate variability device is an example of a medical device that contains medical device software.<\/div><\/div><\/div>\n<h2><span class=\"mw-headline\" id=\"Medical_device_software\">Medical device software<\/span><\/h2>\n<p>The global IEC 62304 standard on the software life cycle processes of medical device software states it's a \"software system that has been developed for the purpose of being incorporated into the medical device being developed or that is intended for use as a medical device in its own right.\"<sup id=\"rdp-ebb-cite_ref-IEC62304_11-1\" class=\"reference\"><a href=\"#cite_note-IEC62304-11\" rel=\"external_link\">[11]<\/a><\/sup> In the U.S., the FDA states that \"any software that meets the legal definition of a [medical] device\" is considered medical device software.<sup id=\"rdp-ebb-cite_ref-MurrayCDRH10_14-0\" class=\"reference\"><a href=\"#cite_note-MurrayCDRH10-14\" rel=\"external_link\">[14]<\/a><\/sup> A similar \"software can be a medical device\" interpretation was also made by the European Union in 2007 with an update to its European Medical Devices Directive, when \"used specifically for diagnostic and\/or therapeutic purposes.\"<sup id=\"rdp-ebb-cite_ref-2007\/47\/EC_15-0\" class=\"reference\"><a href=\"#cite_note-2007\/47\/EC-15\" rel=\"external_link\">[15]<\/a><\/sup>\n<\/p><p>Due to the broad scope covered by these terms, manifold classifications can be proposed for various medical software, based for instance on their technical nature (embedded in a device or standalone), on their level of safety (from the most trivial to the most safety-critical ones), or on their primarily function (treatment, education, diagnostics, and\/or data management).\n<\/p>\n<h3><span class=\"mw-headline\" id=\"Software_as_a_medical_device\">Software as a medical device<\/span><\/h3>\n<p>The dramatic increase in <a href=\"https:\/\/en.wikipedia.org\/wiki\/Smartphone\" title=\"Smartphone\" rel=\"external_link\" target=\"_blank\">smartphone<\/a> usage in the twenty-first century triggered the emergence of thousands of stand-alone health- and medical-related software apps, many falling into a gray or borderline area in terms of regulation. While software embedded into a medical device was being addressed, medical software separate from medical hardware \u2014 referred to by the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Global_Harmonization_Task_Force\" title=\"Global Harmonization Task Force\" rel=\"external_link\" target=\"_blank\">International Medical Device Regulators Forum<\/a> (IMDRF) as \"software as a medical device\" or \"SaMD\"<sup id=\"rdp-ebb-cite_ref-IMDRFSoft13_16-0\" class=\"reference\"><a href=\"#cite_note-IMDRFSoft13-16\" rel=\"external_link\">[16]<\/a><\/sup> \u2014 was falling through existing regulatory cracks. In the U.S., the FDA eventually released new draft guidance in July 2011 on \"mobile medical applications,\" with members of the legal community such as Keith Barritt speculating it should be read to imply \"as applicable to all software ... since the test for determining whether a mobile application is a regulated mobile 'medical' application is the same test one would use to determine if any software is regulated.\"<sup id=\"rdp-ebb-cite_ref-BarrittNew11_17-0\" class=\"reference\"><a href=\"#cite_note-BarrittNew11-17\" rel=\"external_link\">[17]<\/a><\/sup> Examples of mobile apps potentially covered by the guidance included those that regulate an installed <a href=\"https:\/\/en.wikipedia.org\/wiki\/Artificial_cardiac_pacemaker\" title=\"Artificial cardiac pacemaker\" rel=\"external_link\" target=\"_blank\">pacemaker<\/a> or those that analyze images for <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cancer\" title=\"Cancer\" rel=\"external_link\" target=\"_blank\">cancerous<\/a> <a href=\"https:\/\/en.wikipedia.org\/wiki\/Lesion\" title=\"Lesion\" rel=\"external_link\" target=\"_blank\">lesions<\/a>, X-rays and <a href=\"https:\/\/en.wikipedia.org\/wiki\/MRI\" class=\"mw-redirect\" title=\"MRI\" rel=\"external_link\" target=\"_blank\">MRI<\/a>, graphic data such as <a href=\"https:\/\/en.wikipedia.org\/wiki\/EEG\" class=\"mw-redirect\" title=\"EEG\" rel=\"external_link\" target=\"_blank\">EEG<\/a> waveforms as well as <a href=\"https:\/\/en.wikipedia.org\/wiki\/Bedside_monitor\" class=\"mw-redirect\" title=\"Bedside monitor\" rel=\"external_link\" target=\"_blank\">bedside monitors<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Clinical_urine_tests\" title=\"Clinical urine tests\" rel=\"external_link\" target=\"_blank\">urine analyzers<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Glucometer\" class=\"mw-redirect\" title=\"Glucometer\" rel=\"external_link\" target=\"_blank\">glucometer<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Stethoscope\" title=\"Stethoscope\" rel=\"external_link\" target=\"_blank\">stethoscopes<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Spirometer\" title=\"Spirometer\" rel=\"external_link\" target=\"_blank\">spirometers<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Body_mass_index\" title=\"Body mass index\" rel=\"external_link\" target=\"_blank\">BMI<\/a> calculators, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Heart_rate_monitor\" title=\"Heart rate monitor\" rel=\"external_link\" target=\"_blank\">heart rate monitors<\/a> and body fat calculators.<sup id=\"rdp-ebb-cite_ref-YetisenTheReg14_18-0\" class=\"reference\"><a href=\"#cite_note-YetisenTheReg14-18\" rel=\"external_link\">[18]<\/a><\/sup> By the time its final guidance was released in late 2013, however, members of <a href=\"https:\/\/en.wikipedia.org\/wiki\/United_States_Congress\" title=\"United States Congress\" rel=\"external_link\" target=\"_blank\">Congress<\/a> began to be concerned about the how the guidance would be used in the future, in particular with what it would mean to the SOFTWARE Act legislation that had recently been introduced.<sup id=\"rdp-ebb-cite_ref-SlabodkinCongress13_19-0\" class=\"reference\"><a href=\"#cite_note-SlabodkinCongress13-19\" rel=\"external_link\">[19]<\/a><\/sup> Around the same time, the IMDRF were working on a more global perspective of SaMD with the release of its Key Definitions in December 2013, focused on \"[establishing] a common framework for regulators to incorporate converged controls into their regulatory approaches for SaMD.\"<sup id=\"rdp-ebb-cite_ref-IMDRFSoft13_16-1\" class=\"reference\"><a href=\"#cite_note-IMDRFSoft13-16\" rel=\"external_link\">[16]<\/a><\/sup> Aside from \"not [being] necessary for a hardware medical device to achieve its intended medical purpose,\" the IMDRF also found that SaMD also couldn't drive a medical device, though it could be used as a module of or interfaced with one.<sup id=\"rdp-ebb-cite_ref-IMDRFSoft13_16-2\" class=\"reference\"><a href=\"#cite_note-IMDRFSoft13-16\" rel=\"external_link\">[16]<\/a><\/sup> The group further developed <a href=\"https:\/\/en.wikipedia.org\/wiki\/Quality_management_system\" title=\"Quality management system\" rel=\"external_link\" target=\"_blank\">quality management system<\/a> principles for SaMD in 2015.<sup id=\"rdp-ebb-cite_ref-MezherIMDRF15_20-0\" class=\"reference\"><a href=\"#cite_note-MezherIMDRF15-20\" rel=\"external_link\">[20]<\/a><\/sup>\n<\/p>\n<h2><span class=\"mw-headline\" id=\"International_standards\">International standards<\/span><\/h2>\n<p>IEC 62304 has become the benchmark standard for the development of medical device software, whether standalone software or otherwise, in both the E.U. and the U.S.<sup id=\"rdp-ebb-cite_ref-JetleyMed13_3-1\" class=\"reference\"><a href=\"#cite_note-JetleyMed13-3\" rel=\"external_link\">[3]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-RustSoft15_21-0\" class=\"reference\"><a href=\"#cite_note-RustSoft15-21\" rel=\"external_link\">[21]<\/a><\/sup> Leading industry innovation in software technologies has led key industry leaders and government regulators to recognize the emergence of numerous standalone medical software products that operate as medical devices. This has been reflected in regulatory changes in the E.U. (European Medical Devices Directive<sup id=\"rdp-ebb-cite_ref-BecchettiMed13_1-2\" class=\"reference\"><a href=\"#cite_note-BecchettiMed13-1\" rel=\"external_link\">[1]<\/a><\/sup>) and the U.S. (various FDA guidance documents<sup id=\"rdp-ebb-cite_ref-VogelMed11_2-2\" class=\"reference\"><a href=\"#cite_note-VogelMed11-2\" rel=\"external_link\">[2]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FDAOff99_12-1\" class=\"reference\"><a href=\"#cite_note-FDAOff99-12\" rel=\"external_link\">[12]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-FDAGuidance05_13-1\" class=\"reference\"><a href=\"#cite_note-FDAGuidance05-13\" rel=\"external_link\">[13]<\/a><\/sup><sup id=\"rdp-ebb-cite_ref-SlabodkinCongress13_19-1\" class=\"reference\"><a href=\"#cite_note-SlabodkinCongress13-19\" rel=\"external_link\">[19]<\/a><\/sup>). Additionally, quality management system requirements for manufacturing a software medical device, as is the case with any medical device, are described in the U.S. Quality Systems Regulation<sup id=\"rdp-ebb-cite_ref-FDAQSR_22-0\" class=\"reference\"><a href=\"#cite_note-FDAQSR-22\" rel=\"external_link\">[22]<\/a><\/sup> of the FDA and also in <a href=\"https:\/\/en.wikipedia.org\/wiki\/ISO_13485\" title=\"ISO 13485\" rel=\"external_link\" target=\"_blank\">ISO 13485<\/a>:2003. Software technology manufacturers that operate within the software medical device space conduct mandatory development of their products in accordance with those requirements. Furthermore, though not mandatory, they may elect to obtain certification from a <a href=\"https:\/\/en.wikipedia.org\/wiki\/Notified_Body\" title=\"Notified Body\" rel=\"external_link\" target=\"_blank\">notified body<\/a>, having implemented such quality system requirements as described within international standards such as ISO 13485:2003.\n<\/p>\n<h2><span class=\"mw-headline\" id=\"Further_reading\">Further reading<\/span><\/h2>\n<ul><li><cite class=\"citation book\">Becchetti, C.; Neri, A. (2013). \"Chapter 6: Medical Software\". <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=P3VeLRVMdQ8C&pg=PT275\" target=\"_blank\"><i>Medical Instrument Design and Development: From Requirements to Market Placements<\/i><\/a>. Chichester, U.K.: John Wiley & Sons Ltd. pp. 359\u2013418. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 9781119952404.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter+6%3A+Medical+Software&rft.btitle=Medical+Instrument+Design+and+Development%3A+From+Requirements+to+Market+Placements&rft.place=Chichester%2C+U.K.&rft.pages=359-418&rft.pub=John+Wiley+%26+Sons+Ltd&rft.date=2013&rft.isbn=9781119952404&rft.au=Becchetti%2C+C.&rft.au=Neri%2C+A.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DP3VeLRVMdQ8C%26pg%3DPT275&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><\/li>\n<li><cite class=\"citation book\">Degoulet, P.; Fieschi, M. (2012). \"Chapter 2: Medical Software Development\". <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=obfDBAAAQBAJ&pg=PA26\" target=\"_blank\"><i>Introduction to Clinical Informatics<\/i><\/a>. New York: Springer Science & Business Media. pp. 19\u201334. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 9781461268659.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter+2%3A+Medical+Software+Development&rft.btitle=Introduction+to+Clinical+Informatics&rft.place=New+York&rft.pages=19-34&rft.pub=Springer+Science+%26+Business+Media&rft.date=2012&rft.isbn=9781461268659&rft.au=Degoulet%2C+P.&rft.au=Fieschi%2C+M.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DobfDBAAAQBAJ%26pg%3DPA26&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/li><\/ul>\n<h2><span class=\"mw-headline\" id=\"See_also\">See also<\/span><\/h2>\n<ul><li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Health_informatics\" title=\"Health informatics\" rel=\"external_link\" target=\"_blank\">Health informatics<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Health_information_technology\" title=\"Health information technology\" rel=\"external_link\" target=\"_blank\">Health information technology<\/a><\/li>\n<li><a href=\"https:\/\/en.wikipedia.org\/wiki\/Category:Medical_software\" title=\"Category:Medical software\" rel=\"external_link\" target=\"_blank\">Category:Medical software<\/a><\/li><\/ul>\n<h2><span class=\"mw-headline\" id=\"External_links\">External links<\/span><\/h2>\n<p><a href=\"https:\/\/en.wikipedia.org\/wiki\/File:Commons-logo.svg\" class=\"image\" rel=\"external_link\" target=\"_blank\"><img alt=\"\" src=\"https:\/\/upload.wikimedia.org\/wikipedia\/en\/thumb\/4\/4a\/Commons-logo.svg\/12px-Commons-logo.svg.png\" width=\"12\" height=\"16\" class=\"noviewer\" \/><\/a> Media related to <a href=\"https:\/\/commons.wikimedia.org\/wiki\/Category:Medical_Software\" class=\"extiw\" title=\"commons:Category:Medical Software\" rel=\"external_link\" target=\"_blank\">Medical Software<\/a> at Wikimedia Commons\n<\/p>\n<h2><span class=\"mw-headline\" id=\"References\">References<\/span><\/h2>\n<div class=\"reflist columns references-column-width\" style=\"-moz-column-width: 32em; -webkit-column-width: 32em; column-width: 32em; list-style-type: decimal;\">\n<ol class=\"references\">\n<li id=\"cite_note-BecchettiMed13-1\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-BecchettiMed13_1-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-BecchettiMed13_1-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-BecchettiMed13_1-2\" rel=\"external_link\"><sup><i><b>c<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Becchetti, C.; Neri, A. (2013). \"Chapter 6: Medical Software\". <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=P3VeLRVMdQ8C&pg=PT275\" target=\"_blank\"><i>Medical Instrument Design and Development: From Requirements to Market Placements<\/i><\/a>. Chichester, U.K.: John Wiley & Sons Ltd. pp. 359\u2013418. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 9781119952404.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter+6%3A+Medical+Software&rft.btitle=Medical+Instrument+Design+and+Development%3A+From+Requirements+to+Market+Placements&rft.place=Chichester%2C+U.K.&rft.pages=359-418&rft.pub=John+Wiley+%26+Sons+Ltd&rft.date=2013&rft.isbn=9781119952404&rft.au=Becchetti%2C+C.&rft.au=Neri%2C+A.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DP3VeLRVMdQ8C%26pg%3DPT275&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-VogelMed11-2\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-VogelMed11_2-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-VogelMed11_2-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-VogelMed11_2-2\" rel=\"external_link\"><sup><i><b>c<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Vogel, D.A. (2011). \"Chapter 3: The FDA Software Validation Regulations and Why You Should Validate Software Anyway\". <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=LYxH-zUSOTgC&pg=PA27\" target=\"_blank\"><i>Medical Device Software Verification, Validation, and Compliance<\/i><\/a>. Boston, MA: Artech House. pp. 27\u201336. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 9781596934238.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Chapter+3%3A+The+FDA+Software+Validation+Regulations+and+Why+You+Should+Validate+Software+Anyway&rft.btitle=Medical+Device+Software+Verification%2C+Validation%2C+and+Compliance&rft.place=Boston%2C+MA&rft.pages=27-36&rft.pub=Artech+House&rft.date=2011&rft.isbn=9781596934238&rft.au=Vogel%2C+D.A.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DLYxH-zUSOTgC%26pg%3DPA27&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-JetleyMed13-3\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-JetleyMed13_3-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-JetleyMed13_3-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Jetley, R.; Sudarsan, S.; R., Sampath; Ramaswamy, S. (2013). \"Medical Software - Issues and Best Practices\". <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=5I25BQAAQBAJ&pg=PA69\" target=\"_blank\"><i>Distributed Computing and Internet Technology: 9th International Conference, ICDCIT 2013, Bhubaneswar, India, February 5-8, 2013, Proceedings<\/i><\/a>. Hyderabad, India: Springer. pp. 69\u201391. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 9783642360718.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Medical+Software+-+Issues+and+Best+Practices&rft.btitle=Distributed+Computing+and+Internet+Technology%3A+9th+International+Conference%2C+ICDCIT+2013%2C+Bhubaneswar%2C+India%2C+February+5-8%2C+2013%2C+Proceedings&rft.place=Hyderabad%2C+India&rft.pages=69-91&rft.pub=Springer&rft.date=2013&rft.isbn=9783642360718&rft.au=Jetley%2C+R.&rft.au=Sudarsan%2C+S.&rft.au=R.%2C+Sampath&rft.au=Ramaswamy%2C+S.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D5I25BQAAQBAJ%26pg%3DPA69&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-REA63-4\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-REA63_4-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=3WpVAAAAYAAJ&q=%22medical+software%22&dq=%22medical+software%22\" target=\"_blank\">\"Radar and Electronics\"<\/a>. Radar and Electronics Association. March 1963<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Radar+and+Electronics&rft.pub=Radar+and+Electronics+Association&rft.date=1963-03&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D3WpVAAAAYAAJ%26q%3D%2522medical%2Bsoftware%2522%26dq%3D%2522medical%2Bsoftware%2522&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-LHHIS-5\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-LHHIS_5-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation book\"><a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=8vsFGwAACAAJ\" target=\"_blank\"><i>Lockheed Hospital Information System<\/i><\/a>. Lockheed Aircraft Corporation. 1965. p. 82.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Lockheed+Hospital+Information+System&rft.pages=82&rft.pub=Lockheed+Aircraft+Corporation&rft.date=1965&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D8vsFGwAACAAJ&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-DemEvalHos-6\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-DemEvalHos_6-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Gall, John E.; Norwood, Donald D.; El Camino Hospital (1977). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=6RA7YzUXYg8C\" target=\"_blank\"><i>Demonstration and evaluation of a total hospital information system<\/i><\/a>. NCHSR research summary series. U.S. Dept. of Health, Education, and Welfare, Public Health Service, Health Resources Administration, National Center for Health Services Research. p. 38.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Demonstration+and+evaluation+of+a+total+hospital+information+system&rft.series=NCHSR+research+summary+series&rft.pages=38&rft.pub=U.S.+Dept.+of+Health%2C+Education%2C+and+Welfare%2C+Public+Health+Service%2C+Health+Resources+Administration%2C+National+Center+for+Health+Services+Research&rft.date=1977&rft.au=Gall%2C+John+E.&rft.au=Norwood%2C+Donald+D.&rft.au=El+Camino+Hospital&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D6RA7YzUXYg8C&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-ZimmermanComp78-7\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-ZimmermanComp78_7-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Zimmerman, J.; Rector, A. (1978). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=8FprAAAAMAAJ\" target=\"_blank\"><i>Computers for the Physician's Office<\/i><\/a>. Forest Grove, OR: Research Studies Press. p. 305. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 0893550078.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Computers+for+the+Physician%27s+Office&rft.place=Forest+Grove%2C+OR&rft.pages=305&rft.pub=Research+Studies+Press&rft.date=1978&rft.isbn=0893550078&rft.au=Zimmerman%2C+J.&rft.au=Rector%2C+A.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3D8FprAAAAMAAJ&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-FreedmanCons85-8\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-FreedmanCons85_8-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Freedman, E.; Hecht, E.; Whiteside, D. (1985). \"Consultants Perspective on Medical Office Computerization\". <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=xW1LAAAAYAAJ\" target=\"_blank\"><i>Computers in Healthcare, Volume 6<\/i><\/a>. Englewood: Cardiff Publishing Company.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Consultants+Perspective+on+Medical+Office+Computerization&rft.btitle=Computers+in+Healthcare%2C+Volume+6&rft.place=Englewood&rft.pub=Cardiff+Publishing+Company&rft.date=1985&rft.au=Freedman%2C+E.&rft.au=Hecht%2C+E.&rft.au=Whiteside%2C+D.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DxW1LAAAAYAAJ&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-CosgriffQual94-9\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-CosgriffQual94_9-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-CosgriffQual94_9-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Cosgriff, P.S. (1994). \"Quality assurance of medical software\". <i>Journal of Medical Engineering & Technology<\/i>. <b>18<\/b> (1): 1\u201310. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.3109%2F03091909409030782\" target=\"_blank\">10.3109\/03091909409030782<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/PubMed_Identifier\" class=\"mw-redirect\" title=\"PubMed Identifier\" rel=\"external_link\" target=\"_blank\">PMID<\/a> <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/www.ncbi.nlm.nih.gov\/pubmed\/8006924\" target=\"_blank\">8006924<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal+of+Medical+Engineering+%26+Technology&rft.atitle=Quality+assurance+of+medical+software&rft.volume=18&rft.issue=1&rft.pages=1-10&rft.date=1994&rft_id=info%3Adoi%2F10.3109%2F03091909409030782&rft_id=info%3Apmid%2F8006924&rft.au=Cosgriff%2C+P.S.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-JonesAForm10-10\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-JonesAForm10_10-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Jones, P.; Jetley, R.; Abraham, J. (9 February 2010). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.embedded.com\/design\/prototyping-and-development\/4008888\/A-Formal-Methods-based-verification-approach-to-medical-device-software-analysis\" target=\"_blank\">\"A Formal Methods-based verification approach to medical device software analysis\"<\/a>. <i>Embedded<\/i>. UBM<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Embedded&rft.atitle=A+Formal+Methods-based+verification+approach+to+medical+device+software+analysis&rft.date=2010-02-09&rft.au=Jones%2C+P.&rft.au=Jetley%2C+R.&rft.au=Abraham%2C+J.&rft_id=http%3A%2F%2Fwww.embedded.com%2Fdesign%2Fprototyping-and-development%2F4008888%2FA-Formal-Methods-based-verification-approach-to-medical-device-software-analysis&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-IEC62304-11\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-IEC62304_11-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-IEC62304_11-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\">International Electrotechnical Commission (2006). <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/webstore.iec.ch\/preview\/info_iec62304%7Bed1.0%7Den_d.pdf\" target=\"_blank\">\"Medical device software \u2013 Software life cycle processes\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. <i>International Standard IEC 62304, First Edition 2006-05<\/i>. International Electrotechnical Commission<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=International+Standard+IEC+62304%2C+First+Edition+2006-05&rft.atitle=Medical+device+software+%E2%80%93++Software+life+cycle+processes&rft.date=2006&rft.au=International+Electrotechnical+Commission&rft_id=https%3A%2F%2Fwebstore.iec.ch%2Fpreview%2Finfo_iec62304%257Bed1.0%257Den_d.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-FDAOff99-12\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-FDAOff99_12-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-FDAOff99_12-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Office of Device Evaluation, Center for Devices and Radiological Health (9 September 1999). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/MedicalDevices\/...\/ucm073779.pdf\" target=\"_blank\">\"Guidance for Industry, FDA Reviewers and Compliance on Off-The-Shelf Software Use in Medical Devices\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Guidance+for+Industry%2C+FDA+Reviewers+and+Compliance+on+Off-The-Shelf+Software+Use+in+Medical+Devices&rft.pub=U.S.+Food+and+Drug+Administration&rft.date=1999-09-09&rft.au=Office+of+Device+Evaluation%2C+Center+for+Devices+and+Radiological+Health&rft_id=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FMedicalDevices%2F...%2Fucm073779.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-FDAGuidance05-13\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-FDAGuidance05_13-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-FDAGuidance05_13-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Center for Devices; Radiological Health (11 May 2005). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/RegulatoryInformation\/Guidances\/ucm089543.htm\" target=\"_blank\">\"Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices\"<\/a>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Guidance+for+the+Content+of+Premarket+Submissions+for+Software+Contained+in+Medical+Devices&rft.pub=U.S.+Food+and+Drug+Administration&rft.date=2005-05-11&rft.au=Center+for+Devices&rft.au=Radiological+Health&rft_id=http%3A%2F%2Fwww.fda.gov%2FRegulatoryInformation%2FGuidances%2Fucm089543.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-MurrayCDRH10-14\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-MurrayCDRH10_14-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Murray Jr., J.F. (March 2010). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/downloads\/Training\/CDRHLearn\/UCM209129.pdf\" target=\"_blank\">\"CDRH Regulated Software: An Introduction\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. U.S. Food and Drug Administration<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=CDRH+Regulated+Software%3A+An+Introduction&rft.pub=U.S.+Food+and+Drug+Administration&rft.date=2010-03&rft.au=Murray+Jr.%2C+J.F.&rft_id=http%3A%2F%2Fwww.fda.gov%2Fdownloads%2FTraining%2FCDRHLearn%2FUCM209129.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-2007\/47\/EC-15\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-2007\/47\/EC_15-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/eur-lex.europa.eu\/LexUriServ\/LexUriServ.do?uri=OJ:L:2007:247:0021:0055:en:PDF\" target=\"_blank\">\"Directive 2007\/47\/ED of the European Parliament and of the Council\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. <i>Official Journal of the European Union<\/i>. European Union. 5 September 2007<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Official+Journal+of+the+European+Union&rft.atitle=Directive+2007%2F47%2FED+of+the+European+Parliament+and+of+the+Council&rft.date=2007-09-05&rft_id=http%3A%2F%2Feur-lex.europa.eu%2FLexUriServ%2FLexUriServ.do%3Furi%3DOJ%3AL%3A2007%3A247%3A0021%3A0055%3Aen%3APDF&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-IMDRFSoft13-16\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-IMDRFSoft13_16-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-IMDRFSoft13_16-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-IMDRFSoft13_16-2\" rel=\"external_link\"><sup><i><b>c<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Spanou, D. (9 December 2013). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.imdrf.org\/docs\/imdrf\/final\/technical\/imdrf-tech-131209-samd-key-definitions-140901.pdf\" target=\"_blank\">\"Software as a Medical Device (SaMD): Key Definitions\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. International Medical Device Regulators Forum. p. 9<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Software+as+a+Medical+Device+%28SaMD%29%3A+Key+Definitions&rft.pages=9&rft.pub=International+Medical+Device+Regulators+Forum&rft.date=2013-12-09&rft.au=Spanou%2C+D.&rft_id=http%3A%2F%2Fwww.imdrf.org%2Fdocs%2Fimdrf%2Ffinal%2Ftechnical%2Fimdrf-tech-131209-samd-key-definitions-140901.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-BarrittNew11-17\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-BarrittNew11_17-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fr.com\/files\/Uploads\/Documents\/Barritt,%20Keith.%20BNA%20Medical%20Devices%20Law%20&%20Industry%20Report.%20New%20FDA%20Draft%20Guidance.%2008-10-11.pdf\" target=\"_blank\">\"New FDA Draft Guidance Sheds Light On Regulation of 'Mobile Medical Apps' and Other Software\"<\/a> <span class=\"cs1-format\">(PDF)<\/span>. <i>Medical Devices Law & Industry Report<\/i>. <b>5<\/b> (16): 1\u20133. August 2011<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Medical+Devices+Law+%26+Industry+Report&rft.atitle=New+FDA+Draft+Guidance+Sheds+Light+On+Regulation+of+%E2%80%98Mobile+Medical+Apps%E2%80%99+and+Other+Software&rft.volume=5&rft.issue=16&rft.pages=1-3&rft.date=2011-08&rft_id=http%3A%2F%2Fwww.fr.com%2Ffiles%2FUploads%2FDocuments%2FBarritt%2C%2520Keith.%2520BNA%2520Medical%2520Devices%2520Law%2520%26%2520Industry%2520Report.%2520New%2520FDA%2520Draft%2520Guidance.%252008-10-11.pdf&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-YetisenTheReg14-18\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-YetisenTheReg14_18-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation journal\">Yetisen, A.K.; Martinez-Hurtado, J.L.; Vasconcellos, F.C.; Simsekler, M.C.E.; Akram, M.S.; Lowe, C.R. (2014). \"The regulation of mobile medical applications\". <i>Lab on a Chip<\/i>. <b>14<\/b> (5): 833\u2013840. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1039%2FC3LC51235E\" target=\"_blank\">10.1039\/C3LC51235E<\/a>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Lab+on+a+Chip&rft.atitle=The+regulation+of+mobile+medical+applications&rft.volume=14&rft.issue=5&rft.pages=833-840&rft.date=2014&rft_id=info%3Adoi%2F10.1039%2FC3LC51235E&rft.au=Yetisen%2C+A.K.&rft.au=Martinez-Hurtado%2C+J.L.&rft.au=Vasconcellos%2C+F.C.&rft.au=Simsekler%2C+M.C.E.&rft.au=Akram%2C+M.S.&rft.au=Lowe%2C+C.R.&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-SlabodkinCongress13-19\"><span class=\"mw-cite-backlink\">^ <a href=\"#cite_ref-SlabodkinCongress13_19-0\" rel=\"external_link\"><sup><i><b>a<\/b><\/i><\/sup><\/a> <a href=\"#cite_ref-SlabodkinCongress13_19-1\" rel=\"external_link\"><sup><i><b>b<\/b><\/i><\/sup><\/a><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Slabodkin, G. (20 November 2013). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fiercemobilehealthcare.com\/story\/congress-fda-odds-over-software-medical-device\/2013-11-20\" target=\"_blank\">\"Congress, FDA at odds over software as a medical device\"<\/a>. <i>Fierce Mobile Healthcare<\/i>. Questex, LLC.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Fierce+Mobile+Healthcare&rft.atitle=Congress%2C+FDA+at+odds+over+software+as+a+medical+device&rft.date=2013-11-20&rft.au=Slabodkin%2C+G.&rft_id=http%3A%2F%2Fwww.fiercemobilehealthcare.com%2Fstory%2Fcongress-fda-odds-over-software-medical-device%2F2013-11-20&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-MezherIMDRF15-20\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-MezherIMDRF15_20-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\">Mezher, M. (8 April 2015). <a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.raps.org\/Regulatory-Focus\/News\/2015\/04\/08\/21936\/IMDRF-Proposes-QMS-Principles-for-Software-as-a-Medical-Device\/\" target=\"_blank\">\"IMDRF Proposes QMS Principles for Software as a Medical Device\"<\/a>. <i>Regulatory Focus<\/i>. Regulatory Affairs Professionals Society<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=Regulatory+Focus&rft.atitle=IMDRF+Proposes+QMS+Principles+for+Software+as+a+Medical+Device&rft.date=2015-04-08&rft.au=Mezher%2C+M.&rft_id=http%3A%2F%2Fwww.raps.org%2FRegulatory-Focus%2FNews%2F2015%2F04%2F08%2F21936%2FIMDRF-Proposes-QMS-Principles-for-Software-as-a-Medical-Device%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-RustSoft15-21\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-RustSoft15_21-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation book\">Rust, P.; Flood, D.; McCaffery, F. (2015). \"Software Process Improvement and Roadmapping \u2013 A Roadmap for Implementing IEC 62304 in Organizations Developing and Maintaining Medical Device Software\". In Rout, T.; C'Connor, R.V.; Dorling, A. <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/books.google.com\/books?id=u3zMCQAAQBAJ&pg=PA19\" target=\"_blank\"><i>Software Process Improvement and Capability Determination<\/i><\/a>. Cham, Switzerland: Springer. pp. 19\u201332. <a href=\"https:\/\/en.wikipedia.org\/wiki\/Digital_object_identifier\" title=\"Digital object identifier\" rel=\"external_link\" target=\"_blank\">doi<\/a>:<a rel=\"external_link\" class=\"external text\" href=\"https:\/\/doi.org\/10.1007%2F978-3-319-19860-6_3\" target=\"_blank\">10.1007\/978-3-319-19860-6_3<\/a>. <a href=\"https:\/\/en.wikipedia.org\/wiki\/International_Standard_Book_Number\" title=\"International Standard Book Number\" rel=\"external_link\" target=\"_blank\">ISBN<\/a> 9783319198606.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=bookitem&rft.atitle=Software+Process+Improvement+and+Roadmapping+%E2%80%93+A+Roadmap+for+Implementing+IEC+62304+in+Organizations+Developing+and+Maintaining+Medical+Device+Software&rft.btitle=Software+Process+Improvement+and+Capability+Determination&rft.place=Cham%2C+Switzerland&rft.pages=19-32&rft.pub=Springer&rft.date=2015&rft_id=info%3Adoi%2F10.1007%2F978-3-319-19860-6_3&rft.isbn=9783319198606&rft.au=Rust%2C+P.&rft.au=Flood%2C+D.&rft.au=McCaffery%2C+F.&rft_id=https%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3Du3zMCQAAQBAJ%26pg%3DPA19&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<li id=\"cite_note-FDAQSR-22\"><span class=\"mw-cite-backlink\"><b><a href=\"#cite_ref-FDAQSR_22-0\" rel=\"external_link\">^<\/a><\/b><\/span> <span class=\"reference-text\"><cite class=\"citation web\"><a rel=\"external_link\" class=\"external text\" href=\"http:\/\/www.fda.gov\/medicaldevices\/deviceregulationandguidance\/postmarketrequirements\/qualitysystemsregulations\/default.htm\" target=\"_blank\">\"Quality System (QS) Regulation\/Medical Device Good Manufacturing Practices\"<\/a>. U.S. Food and Drug Administration. 30 June 2014<span class=\"reference-accessdate\">. Retrieved <span class=\"nowrap\">26 April<\/span> 2016<\/span>.<\/cite><span title=\"ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Quality+System+%28QS%29+Regulation%2FMedical+Device+Good+Manufacturing+Practices&rft.pub=U.S.+Food+and+Drug+Administration&rft.date=2014-06-30&rft_id=http%3A%2F%2Fwww.fda.gov%2Fmedicaldevices%2Fdeviceregulationandguidance%2Fpostmarketrequirements%2Fqualitysystemsregulations%2Fdefault.htm&rfr_id=info%3Asid%2Fen.wikipedia.org%3AMedical+software\" class=\"Z3988\"><\/span><link rel=\"mw-deduplicated-inline-style\" href=\"mw-data:TemplateStyles:r861714446\"\/><\/span>\n<\/li>\n<\/ol><\/div>\n<p><!-- \nNewPP limit report\nParsed by mw1321\nCached time: 20190102134249\nCache expiry: 1900800\nDynamic content: false\nCPU time usage: 0.340 seconds\nReal time usage: 0.430 seconds\nPreprocessor visited node count: 1248\/1000000\nPreprocessor generated node count: 0\/1500000\nPost\u2010expand include size: 46860\/2097152 bytes\nTemplate argument size: 342\/2097152 bytes\nHighest expansion depth: 9\/40\nExpensive parser function count: 1\/500\nUnstrip recursion depth: 1\/20\nUnstrip post\u2010expand size: 68580\/5000000 bytes\nNumber of Wikibase entities loaded: 2\/400\nLua time usage: 0.203\/10.000 seconds\nLua memory usage: 5.99 MB\/50 MB\n-->\n<!--\nTransclusion expansion time report (%,ms,calls,template)\n100.00% 356.739 1 -total\n<\/p>\n<pre>46.96% 167.541 1 Template:Reflist\n36.13% 128.903 10 Template:Cite_book\n27.82% 99.258 1 Template:Commonscat-inline\n13.99% 49.892 11 Template:Cite_web\n 8.84% 31.523 3 Template:Cite_journal\n 2.48% 8.840 2 Template:Replace\n 1.42% 5.048 1 Template:Sister-inline\n 0.67% 2.401 1 Template:Main_other\n 0.65% 2.316 1 Template:Column-width\n<\/pre>\n<p>-->\n<\/p><p><!-- Saved in parser cache with key enwiki:pcache:idhash:467919-1!canonical and timestamp 20190102134248 and revision id 855776126\n<\/p>\n<pre>-->\n<\/pre>\n<\/div>\n<h2><span class=\"mw-headline\" id=\"Notes\">Notes<\/span><\/h2>\n<p>This article is a direct transclusion of <a rel=\"external_link\" class=\"external text\" href=\"https:\/\/en.wikipedia.org\/wiki\/Medical_software\" target=\"_blank\">the Wikipedia article<\/a> and therefore may not meet the same editing standards as LIMSwiki.\n<\/p>\n<!-- \nNewPP limit report\nCached time: 20190104224850\nCache expiry: 86400\nDynamic content: false\nCPU time usage: 0.022 seconds\nReal time usage: 0.134 seconds\nPreprocessor visited node count: 5\/1000000\nPreprocessor generated node count: 20\/1000000\nPost\u2010expand include size: 20\/2097152 bytes\nTemplate argument size: 0\/2097152 bytes\nHighest expansion depth: 2\/40\nExpensive parser function count: 0\/100\n-->\n\n<!-- \nTransclusion expansion time report (%,ms,calls,template)\n100.00% 121.618 1 - wikipedia:Medical_software\n100.00% 121.618 1 - -total\n-->\n\n<!-- Saved in parser cache with key limswiki:pcache:idhash:8113-0!*!*!*!*!*!* and timestamp 20190104224850 and revision id 24234\n -->\n<\/div><div class=\"printfooter\">Source: <a rel=\"external_link\" class=\"external\" href=\"https:\/\/www.limswiki.org\/index.php\/Medical_software\">https:\/\/www.limswiki.org\/index.php\/Medical_software<\/a><\/div>\n\t\t\t\t\t\t\t\t\t\t<!-- end content -->\n\t\t\t\t\t\t\t\t\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<!-- end of the left (by default at least) column -->\n\t\t<div class=\"visualClear\"><\/div>\n\t\t\t\t\t\n\t\t<\/div>\n\t\t\n\n<\/body>","79dbc75d9223c22375492817dbae2161_images":["https:\/\/upload.wikimedia.org\/wikipedia\/commons\/thumb\/7\/7d\/Portable_heart_rate_variability_device.JPG\/500px-Portable_heart_rate_variability_device.JPG","https:\/\/upload.wikimedia.org\/wikipedia\/en\/thumb\/4\/4a\/Commons-logo.svg\/24px-Commons-logo.svg.png"],"79dbc75d9223c22375492817dbae2161_timestamp":1546642130,"c6ef2386172692589fafa53e57da849e":{"type":"chapter","title":"1. What Are Medical Software and Devices?","key":"c6ef2386172692589fafa53e57da849e"}},"link":"https:\/\/www.limswiki.org\/index.php\/Book:Software_Development_for_Medical_Devices_Using_Continuous_Integration","price_currency":"","price_amount":"","book_size":"","download_url":"https:\/\/www.limsforum.com?ebb_action=book_download&book_id=78536","language":"","cta_button_content":"","toc":[{"type":"chapter","name":"1. What Are Medical Software and Devices?","id":"c6ef2386172692589fafa53e57da849e","children":[{"type":"article","name":"Medical software","id":"79dbc75d9223c22375492817dbae2161","pageUrl":"https:\/\/www.limswiki.org\/index.php\/Medical_software"},{"type":"article","name":"Medical device","id":"8e821122daa731f0fa8782fae57831fa","pageUrl":"https:\/\/www.limswiki.org\/index.php\/Medical_device"},{"type":"article","name":"Further defining medical device software","id":"fb5fecbcef204bee669859f6511678d4","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Defining_Medical_Device_Software"}]},{"type":"chapter","name":"2. Introduction to Continuous Integration for Medical Device Software Development","id":"ebfc6d45221441e939b563c23c3f89a3","children":[{"type":"article","name":"Introduction","id":"613f1316ca7e0f1ba75417bfe2747d39","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Introduction"},{"type":"article","name":"Why continuous integration?","id":"8aa7cf5a1a2f18bd7ab6b7269eff4787","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration"},{"type":"article","name":"CI theory, practices, and tools","id":"a2777f409854379de217cacc4dde9d3a","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Continuous_Integration:_Part_2"}]},{"type":"chapter","name":"3. Applying Continuous Integration Practices to Medical Device Software Development","id":"e11626816a101e5a61c1cd49af3a6574","children":[{"type":"article","name":"Version control","id":"216ba38dff8063ab9365f6477c058f2c","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Version_Control"},{"type":"article","name":"Validation","id":"fe175ec1d1846bbf56d90860f4b8b11a","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Validation"},{"type":"article","name":"Practical application of Agile","id":"c52457e4a7209968c2325bdf3bcebdb3","pageUrl":"https:\/\/www.limswiki.org\/index.php\/LII:Medical_Device_Software_Development_with_Continuous_Integration\/Practical_Application_of_Agile"}]}],"settings":{"show_cover":"1","show_title":"1","show_subtitle":"0","show_full_title":"1","show_editor":"1","show_editor_pic":"1","show_publisher":"1","show_language":"1","show_size":"1","show_toc":"1","show_content_beneath_cover":"1","cta_button":"1","content_location":"1","toc_links":"disabled","log_in_msg":"<span><\/span> Please log in to read online.","cover_size":"medium"},"title_image":"https:\/\/s3.limsforum.com\/www.limsforum.com\/wp-content\/uploads\/Continuous-integration-dhf.jpg"}}
Copyright LabLynx Inc. All rights reserved.