Tuesday, November 3, 2015, 20 representatives for a number of companies with interests in medical technology gathered in Jonsered, Sweden for to exchange what we knew about managing software projects in this environment, a meeting facilitated by Mediteq Forum
The site for the venue was the beautifully located Jonsereds Herrgård, now operated by Gothenburg University. The day was not the best, with the fantastic view from the front porch somewhat diminished by heavy rain clouds, and the water in the taps being unsuitable for drinking due to an incident at the nearby waterworks. Luckily, the participants were all informed of this fact upon arrival, and adequate replacements in the form of tea and coffee were provided.
Some of the questions we wanted to discuss were:
In what way is software a part of the companies products?
How is the process managed and what problems are faced?
What tools are used?
What can we learn from each other?
The majority of the participants were software developers or project managers from companies providing medtech solutions, where software is only part of the deliverables. A few came from pure software companies, who also provide solutions for medtech. The structure of the meeting was a short update on latest information from representatives for Mediteq, after which a discussion between the participants followed, with some opportunity for mingling. The discussion focused on points of IT security, testing procedures, tools, risk and requirements analysis and the fulfillment of governmental requirements and international standards.
One point of major interest was the latest information on the standards IEC 62304:2015
and TR 80002-1:2009, and the latest on the not yet published IEC 82304. Some discussion take place along the system definition and classification of medical software, where the 2015 addition to 62304 is helpful in its definition. Most participants agreed that it is very hard to classify any software, used in a medical environment as A, C being the most common. The reason for this is that probability is not included in the risk classification, only the severity. In other words, if an application can cause severe injury to a patient, it will always be classified as C, no matter how unlikely the incident is, and even if the system requires failure on several levels in order to cause that injury.Sometimes it may be possible to separate systems into parts, after which the least critical parts could be classified as A. But in practice, the extra effort in separating the system is questionable, if the majority of the software is in any case undergoing scrutiny as class C. (A useful explanation by the classification system is given by Mitch).
One of the more useful outcomes was a survey among the participants resulting in a list of the most popular tools for process management (published below). The general opinion was that this meeting was very useful, both as an opportunity to exchange tips-and-tricks and to network. For many of the participants, this was a rare opportunity to exchange information with colleagues in the same field, and an opportunity which, sadly, does not come around often enough through other channels.
Most popular tools among the participants
For Requirement Management we used:
For Implementation we used:
– TFS/Visual Studio
– Enterprise architecture
For Verification we used:
– PC-Lint (statical code analysis)
– CppUnit (unit test)
– NUnit (automatic systemtest)
– TFS/Test Manager
For Release we used:
For Change Management we used: