Documente Academic
Documente Profesional
Documente Cultură
Case example
You are a medical device company and you want to replace your old products by “smart” ones. Your competitors are doing it and you customers want them.
“Smart” means something like an tiny computer (its amazing how small they are), with an operating system and big software. For electronic stuff, you have your
own engineers or you have your subcontractors, which you have been working for 20 years with. They knew how to design embedded software on microchips. But
they don’t know how to design software of higher level, with intelligent behaviour and complex algorithms.
Foreword
This article reflects my point of view on how the development of software integrated in a medical device should be externalized to a 3rd party company. It is
assumed that this company has a good knowledge of software development but no or poor knowledge of software development standards for medical devices.
Especially, he doesn’t have knowledge of IEC 62304, the main standard for software in medical devices and ISO 13485 plus ISO 14971, generic standards for
medical devices.
By the way, if you forecast to launch a software development project, which lasts more than one year, this is too much. Consider splitting it into smaller projects with
multiple versions of your software. This rule of thumb is not specific to software in medical devices.
Specifications
The software development process begins with specifications. In this phase, there is a lot to do with the end user or a group of experts like a medical advisory
board. There are things you can’t delegate to your subcontractor.
First, risk assessment and conformity of the software to your statement of work. You may invite your subcontractor to risk assessment meetings. His ideas may
be of great interest for risk assessment, based on his software knowledge. But the risk assessment activities shall remain your responsibility.
Second, usability and human factors. You shall manage usability specifications by yourself. You may invite your subcontractor to usability specifications
meetings and reviews as well. Better, you should present mock-ups of software to end users, if possible, made by your subcontractor. But the usability
specifications remain your responsibility.
Third, the overall behaviour of the software. The inputs, outputs, expected results, algorithms used, and so on, translated into specifications are your
responsibility. Your subcontractor’s responsibility it to have the internals of software work to meet your requirements.
Conception
The software development process continues with conception. This phase is a hard work for your subcontractor. It has to translate your technical requirements into
software architecture. Conception is split in two sub phases:
The first is like drawing the plan of a building and the last is like designing each room and water / electricity networks. For small projects, they are merged in a
single phase.
Coding
The next phase is called coding. In this phase, software engineers do strange things on their computers and, tadaa, at the end you have your software. Huh, not
yet! There’s still a lot to do.
It is often necessary to have the user manual before doing any tests. Hence the user manual is a good way to understand what is in the tests. You shall write
user/admin/maintenance manuals because they always contain information about risk mitigation actions like safety warnings. And because only you knows how to
write and talk to your customer. But it is not easy to write a user manual of a software you don’t know perfectly yet. The solution is to let your subcontractor
initialise the document with the minimum information, like the software workflows. This draft manual shall exist at the end of the coding phase. Verifying the
content of a user manual is also a task to do in tests.
Verification:
Tests, tests and tests
Whereas you were little involved in the coding phase, you are going to be very involved in the test phase. Test phase may be very long and split in many tests
sessions. Usually, tests are split in three phases:
These phases, especially the third, shouldn’t be confused with clinical tests. Clinical tests happen after verification.
Delivery
The delivery phase is very short compared to the verification phase. It basically aims at delivering the good version of the software, with its documentation and
data, if any.
Delivery content
Your subcontractor should give you a CD or a DVD with your software in its final version after the tests, and everything, which is necessary to rebuild the software
from code. It is your responsibility to store the content of this media in a well-defined place, with its documentation and any documentation you have done by
yourself. This step is important. Hence in real life there is never one delivery but many deliveries. It’s an iterative process to find and fix bugs. Even after tests, some
bugs may be found in very specific conditions, which were not met before.
Problem resolution
There are many bugs, most of them very minor, found during the use of your devices by end users. When almost bugs have been found, your company decides to
launch a new version of your device. Of course, it contains new software functions, with bugs. For these reasons, one can say that software is never finished. It’s
always evolving. For this reason, it’s important to track any bug found during the operational use of your software. A process was invented for this activity:
problem resolution. Problem resolution means to you tracking any issue arisen by someone, which uses the device. During the development process, this is easy,
since your company controls the use of the device prototype. But after delivery, you shall track any issue arisen by end users. This is typically the same process as
post market surveillance, adapted to software.
Things to do
For that purpose, you shall maintain a list of all bugs, comments, and enhancements, issued by end users. And you shall have your subcontractor fix them
periodically, say, twice every year. If the bug is major, for example, a software crash and device reboot happened in the hands of one end-user, you shall have your
subcontractor fix the bug in emergency, to be able to deliver patches to your customers. By the way, your device shall contain a mean to patch software (eg usb
slot + patch function from usb stick).
Validation
There is often a confusion between verification and validation. Whereas the verification can be assimilated to the tests phases of software, validation is the review
of the whole medical device with software. Especially, validation is reviewing that the device is in total conformance with its intended use. Validation is a kind of
final clearance. This is and will remain your job. Your subcontractor has nothing to do with it eventually.
You need all this documentation to compile the technical files you submit to reviewers of regulation organisations. This documentation allows reviewers
understanding how your software was developed. Reviewers love knowing how software is developed, to reassure them on the fact that it is risks free.
Templates are a hard stuff to write, I regularly post some on my blogs. Have a look at the Templates repository page (/pages/Software-Development-Process-
templates), you may find one interesting for you. If not now, maybe later on. And templates suggestions are welcome. Please give me feedback by mail.
Conclusion
If you follow the right standards and have the right procedures, subcontracting a software development project is not too hard a task. If I could give three advices
(yes, I can't stop myself giving advices!),
These advices are not very specific and you may think I state the obvious. In the light of standards for medical devices, this is really important. If you don’t follow
these rules, you will hardly get the certification.
Add a comment
Name or nickname :
Email address :
Website (optional) :
Comment :
preview send
This post's comments feed (http://blog.cm-dm.com/feed/atom/comments/40)
Find
ok
Links
(http://www.md101consulting.com/en)
Go to MD101 website (http://www.md101consulting.com/en)
Contact me
Contact me (http://blog.cm-dm.com/contact)
Pages
About me (http://blog.cm-dm.com/pages/About-me)
Creative Commons License (CC-BY-ND) (http://blog.cm-dm.com/pages/Creative-Commons-License-%28CC-BY-ND%29)
Disclaimer (http://blog.cm-dm.com/pages/Disclaimer)
How to qualify, classify and CE mark software (http://blog.cm-dm.com/pages/How-to-qualify%2C-classify-and-CE-mark-software)
Templates Repository for Software Development Process (http://blog.cm-dm.com/pages/Software-Development-Process-templates)
The essential list of guidances for software medical devices (http://blog.cm-dm.com/pages/The-essential-list-of-guidances-for-software-medical-devices)
Why this blog? (http://blog.cm-dm.com/pages/About)
Home (http://blog.cm-dm.com/)
Archives (http://blog.cm-dm.com/archive)
Categories
Standards (http://blog.cm-dm.com/category/Standards) (45)
Templates (http://blog.cm-dm.com/category/Templates) (23)
Read me first (http://blog.cm-dm.com/category/Read-me-first) (2)
Regulations (http://blog.cm-dm.com/category/Regulations) (50)
Processes (http://blog.cm-dm.com/category/Processes) (24)
Misc (http://blog.cm-dm.com/category/Misc) (40)
Keywords
Agile (http://blog.cm-dm.com/tag/Agile)
CE Mark (http://blog.cm-dm.com/tag/CE%20Mark)
Classification (http://blog.cm-dm.com/tag/Classification)
critical software (http://blog.cm-dm.com/tag/critical%20software)
development process (http://blog.cm-dm.com/tag/development%20process)
FDA (http://blog.cm-dm.com/tag/FDA)
Guidance (http://blog.cm-dm.com/tag/Guidance)
IEC 62304 (http://blog.cm-dm.com/tag/IEC%2062304)
IEC 62366 (http://blog.cm-dm.com/tag/IEC%2062366)
IMDRF (http://blog.cm-dm.com/tag/IMDRF)
ISO 13485 (http://blog.cm-dm.com/tag/ISO%2013485)
ISO 14971 (http://blog.cm-dm.com/tag/ISO%2014971)
mHealth (http://blog.cm-dm.com/tag/mHealth)
mobile medical app (http://blog.cm-dm.com/tag/mobile%20medical%20app)
risk management (http://blog.cm-dm.com/tag/risk%20management)
software failure (http://blog.cm-dm.com/tag/software%20failure)
Software Validation (http://blog.cm-dm.com/tag/Software%20Validation)
Software Verification (http://blog.cm-dm.com/tag/Software%20Verification)
SOUP (http://blog.cm-dm.com/tag/SOUP)
Template (http://blog.cm-dm.com/tag/Template)
Subscribe
Entries feed (http://blog.cm-dm.com/feed/atom)
Comments feed (http://blog.cm-dm.com/feed/atom/comments)
Blogroll
MD101 Consulting (http://www.md101consulting.com/en)
Qualitiso.com (in French) (http://www.qualitiso.com)
HITSphere (http://www.hitsphere.com/)
The Healthcare Technology Guy (http://www.healthcareguy.com)
Bob on medical device software (http://rdn-consulting.com/blog/)