Search the Elsmar Cove!
**Search ALL of Elsmar.com** with DuckDuckGo Especially for content not in the forum
Such as files in the Cove "Members" Directory

Management of Software version while NB reviews Technical file

François

Starting to get Involved
#1
Hi all,

We are CE marked for a class IIa medical device. It's an aid in diagnosis for adult. We would like to extend the intended use to children.
The SW will have to be modified to fit with the new intended use.

We would like to be able to continue to update the App while the NB reviews the technical file and gives us their approval for this substantial change. Since it may take some times. I doubt they will have to do it before may 2020, but management asks me to try.

I was wondering if the following strategy would be OK or if you have a better suggestion.

Current SW: V1.2.0

Tech File send to NB for extension to children : SW V1.3.0, (will never be placed on the market).

NB reviews the Tech File

Update of SW : V1.3.1 (placed on the market)
  • removal of children feature
  • other updates
NB finishes the review and is OK.

Update of SW: V1.4.0 (placed on the market)
  • add children feature
  • other updates

I think I will apply the same strategy for IFU versioning.

Thanks for your advices.
 

yodon

Staff member
Super Moderator
#3
A couple of things (also) jump out at me. First, "removal of children features" would be, for me, a big risk. Why not evolve a common baseline, branch off the child line, and then merge when releasing the child line? Removal of code (if that's where you're heading) is always risky - removing too much; not removing everything. The risks are the same if you're just commenting out the code. If you just disable the feature, you effectively would have "dead code" which nobody likes.

The second thing is "other updates" - if these are considered substantial, the NB would need to be notified anyway.

As @dgrainger is implying (I think), it's unlikely the tech file for the child line would be accepted without clinical data (on children).
 

François

Starting to get Involved
#4
Thanks for your answers @dgrainger

We will have a clinical validation for the children. We've got already the raw data that are required by our algorithm to validate it. Thus, there will have no real clinical investigation with our device. That's what we've previously done for adults.

Regarding your remark @yodon, it's a bad wording on my side. We are planning to make a branch with the child feature (V1.3.0). Then go back to the master branch for the minor updates (V1.3.1) then merge the child branch with the master branch when we've got the go from the NB.

Do you think, we need to comment this strategy in our documentation?
 

yodon

Staff member
Super Moderator
#7
Do you think, we need to comment this strategy in our documentation?
Before answering, I'd have to ask who would the documentation be intended for? If for internal consumption, by all means. If external, it's not anything that would need to be communicated, IMO. It should be just a part of normal SCM.
 

François

Starting to get Involved
#8
Thanks @yodon.
It was mainly to have a record that explains the strategy in case of questions by our NB during audit in few months. But I think that our SW team can explain that without any problem. And it will be probably explain in our documentation that details each release content.
 
Top Bottom