ISO13485:2016 Clause 4.2.3 - Changes in Technical File Requirements

[RA Lille]

Dear all ,
As you know ISO 13485:2016 now contains a clause about technical file of the medical device (clause 4.2.3).

As part as this requirement has been newly written down in the ISO text, what's really new ?

we received an e-mail from our NB saying that "requirements for technical file are becoming more strict and you're asked to take them in consideration".

Does anyone know what 'more strict' means ?
Has anyone already experienced technical file audit according to new ISO 13485:2016 ?
Any idea of what will be deciphered by the auditors ?

Any idea or tool is welcome !

thanks !

 

[yodon]

Can't answer your questions but would certainly like to see this discussion advanced.

Certainly, the overall expectations are increasing. With the latest version of 60601 (3rd edition, amendment 1, I think), there's a detailed review of the Risk File (assessment of compliance to 14971), a review of software design artifacts (compliance to 62304), and a review of the Usability Engineering File (to assess compliance to IEC 62366).

My understanding is if these aren't assessed by a certified test lab, the NB will have to do the detailed review (at extra cost to the manufacturer).

While not exactly imminent, the transition from the MDD to the MDR will probably also have some impact.

Have you asked you NB for any particulars? Again, I'd certainly be interested in hearing where all this is headed.

 

[Ronen E]

Dear all ,
As you know ISO 13485:2016 now contains a clause about technical file of the medical device (clause 4.2.3).

As part as this requirement has been newly written down in the ISO text, what's really new ?

we received an e-mail from our NB saying that "requirements for technical file are becoming more strict and you're asked to take them in consideration".

Does anyone know what 'more strict' means ?
Has anyone already experienced technical file audit according to new ISO 13485:2016 ?
Any idea of what will be deciphered by the auditors ?

Any idea or tool is welcome !

thanks !

Hi,

I've briefly reviewed the topic and here is what I found.

There really isn't much of a material change. It's more a matter of elaborating the requirement. I think that in practice there shouldn't be grave repercussions.

ISO 13485:2003 had the following paragraph under 4.2.1 (Documentation Requirements / General):

For each type or model of medical device, the organization shall establish and maintain a file either containing or identifying documents defining product specifications and quality management system requirements (see 4.2.3). These documents shall define the complete manufacturing process and, if applicable, installation and servicing.

(The emphasis is mine, to highlight the bits that are relevant to ISO 13485:2016 4.2.3).

In essence this is almost identical to the new requirement.

Annex A to ISO 13485:2016 (comments on change between the 2016 and 2003 versions) only states (under 4.2) "Lists the documents that would be included in the medical device file". In that regard, yes, maybe the 2016 version is a little more detailed, but I don't see anything new in it except for explicitly calling out labelling, intended use and IFU (in my view these are part of the device specification, though) and the various aspects of device manufacturing (in my opinion measuring and monitoring are definitely integral parts of device manufacture). Please note that manufacturers following the MDD Annex VII had to have all that in their Tech Files anyway.

Perhaps the only significant difference is the requirement that the File will support demonstrating compliance with ISO 13485 and with applicable regulatory requirements. In the case of NB scrutiny, the latter is mostly complied with via the ER checklist (or similar) that was included in the File anyway. The former, though, as well as full comliance with the latter, might call for an extended checklist that addresses each and every requirement in ISO 13485:2016 and the applicable requirements in the relevant MDD conformity assessment Annex.

Again, I think that in practice you shouldn't see any heightened requirements, it's more a case of formalising the existing practice.

Cheers,
Ronen.

 

[Marcelo]

The final revised requirement in fact is not right (this was a problem we had by dividing the revision work in several groups).

The expectation when we revised the requirement was to have a more clear requirement for a technical file/DMR (we also created a separate file for device design in 7.3.10) because the original requirement rom 2003 mixed both.

The requirement as published requires that you have a file "containing or referencing documents generated to demonstrate conformity to the requirement of this International Standard and compliance with applicable regulatory requirements".

One interpretation of this, for example I that this file has have documents that show how to you comply with ISO 13485 (a checklist with file links, maybe?) and all applicable regulatory requirements (this would be crazy).

Please note that are several more topics in the final text of ISO 13485 that are somewhat weird if you really read the standard with scrutiny (I counted some 30 + last time I revised the standard for the last time when publishing our Brazilian version).

Hopefully some of those can be solved in the guidance document that's going to be published in 2017.

 

[Ronen E]

One interpretation of this, for example I that this file has have documents that show how to you comply with ISO 13485 (a checklist with file links, maybe?) and all applicable regulatory requirements (this would be crazy).

Hi,

1. Why do you think that "would be crazy"?
2. What other interpretations do you have in mind for that clause?

Thanks,
Ronen.

 

[Marcelo]

1. Why do you think that "would be crazy"?

Well, the checklist in the case of Iso 13485 would have to separate all the standard requirements with a line for each requirement (how much would that be, 200 requirements?) and show compliance with everyone of them.

Now imagine doing the same for each specific requirement in each specific regulations that you need to comply.

Besides, I don't think this would fit well in a QMS standard, why would a QMS standard require that? I tried to include a requirement for manufacturers to have at least a procedure to define how they register a product (which I think is extremely reasonable) and even this was not accepted because it would be too much of a burden (what we ended up was with the requirement that "The organization shall communicate with regulatory authorities in accordance with applicable regulatory requirements".).

Hi,
2. What other interpretations do you have in mind for that clause?

Well, another one would be a mix of both, a technical file + monstrous spreadsheet with all applicable requirement of ISO 13485 and applicable regulations and the real documents that show compliance with each specific requirement.

 

[Ronen E]

Thanks for your explanations, Marcelo.

Well, the checklist in the case of Iso 13485 would have to separate all the standard requirements with a line for each requirement (how much would that be, 200 requirements?) and show compliance with everyone of them.

Now imagine doing the same for each specific requirement in each specific regulations that you need to comply.

I don't see that as much different from what manufacturers are currently being expected to present on audit. For example see the ER checklist that has become the standard although it is not explicitly required in the MDD. It's not like that checklist only has a few lines / requirements...

Bottom line, regulatory authorities and certification auditors don't expect manufacturers to start looking for supporting evidence on audit day and they don't expect a lot of verbal debating over meeting the requirements. You could say that they expect to be "spoon fed" with compliance evidence, but I think it makes some sense in terms of audit efficiency, audit duration and total cost (which is eventually rolled over to manufacturers).

Well, another one would be a mix of both, a technical file + monstrous spreadsheet with all applicable requirement of ISO 13485 and applicable regulations and the real documents that show compliance with each specific requirement.

In my opinion that's not really another interpretation, it's just another way of implementing the same approach.

I think that s. 4.2.3 is written quite clearly and indeed there is some added burden in it, however that added burden is not directly related to the device's Tech File. Rather, it is in the need for documenting how ISO 13485:2016 is met. Seems like this was included in 4.2.3 by mistake because it's not directly related to the product; it's more about the organisation and its QMS.

Documenting regulatory compliance in detail is not a huge addition in most cases I know because the regulation often requires such documentation anyway, at least to a large extent.

Cheers,
Ronen.

 

[RA Lille]

Dear all,

thanks for this interesting debate.
As Ronen said, the supporting evidences to demonstrate that QMS is compliant with ISO13485 is not part of the MD tech file, but should be displayed pieces after pieces to feed the certification auditor.

Moreover, compliance with all applicable regulatory requirements should be supported by the general procedure for compliance with regulations and communication with competent authorities. It's RA stuff...

Cheers,

 

[Philip B]

Apologies I am a little late to this interesting debate but I have just started to amend our QMS to 13485:2016. It strikes me that 4.2.3 (a) and (b) are technical file requirements and (c) - (f) are QMS requirements. Therefore I am not sure how best to demonstrate this within our system - or perhaps it doesn't matter as long as they are addressed somewhere? Has anyone had a transition audit and can therefore shed some light on this?

 

[b-quality]

I'm confused by this discussion. In Clause 4.2.3 of ISO 13485:2016 (Medical Device File) I was told this was an expanded version of the FDA DMR. No mention was made to a Tech File. Can anyone elaborate on this?