Regulatory Open Forum

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Hello Anon,

This topic always leads to many opinions about whether to list the revision/version of a document in quality system documents/records because of the eventuality these documents "get out of date" because the revision/version is wrong.  (And this just does not apply to a GSPR matrix, but many other documents.)  Having gone through many audits, I would say it is a 50/50 consensus as 50% auditors want the revision/version and 50% auditors is not relevant to them.  You are exactly right that putting in a document and revision/version in a GSPR matrix depending on the evolution of the device, the GSPR matrix can get out of date fairly quickly.  Right or wrong, I do not put revision/version in the GSPR matrix for the exact reason you specified.  For a complex device, the GSPR will end up at revision/version 210 in a short amount of time trying to keep up to date with all the referenced documents being changed.

There are few approaches which could be taken:

• If the product evolution is stable, then put in the revision/version level within the GSPR and update when appropriate or in a defined period.
• If the product evolution is stable or changing alot, do not put in the revision/version level with only the document reference.
• When putting in the revision/version in the GSPR, write in your Technical Documentation Management procedure, the GSPR is valid on date published and then put in a requirement to update the GSPR with "new" revision/version of the referenced documents periodically, e.g. every 6 months or 12 months.  (This still takes a lot of work to make sure everything is updated correctly.)
• In the GSPR, put a dynamic link to the location of the document, therefore it does not matter if the revision/version is listed or not.  The only issue with this approach, is when sending external those links might not function properly.

For me, I have seen all of these used and even a couple others.  Whatever process you use for completing the GSPR matrix, describe this completely in your technical documentation management procedure so when going through an external audit, you can say you are following your own procedure.  Regardless of what regulations say, and how interpretation may be made, there needs to be some pragmatism for managing documentation within a quality system.  I would rather have a discussion with an auditor about why they think my procedure is not following the regulation (interpretation) rather than a silly observation because a couple revisions are out of date in my GSPR.

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Kevin, I can appreciate your response.  It is technically correct and reflects a strict interpretation of the requirement.  However, I wasn't looking for a strict interpretation of the requirements.  I was looking for a practical and maintainable solution.  In the perfect world, with unlimited resources and ever ending schedules, I would agree that every document revision should be reflected in the GSPR matrix.  However, our world is far from perfect.  Our regulators encourage us to take a risk based approach towards compliance.  Here is a good example of where compliance can be metered by risk.  So, what is the risk of not including document revisions in a GSPR?  I could argue that each revision of a document represents compliance at a point in time.  If I present a GSPR that includes only the document number and then provide the most current version of that document, that represents the current state of compliance.  If it does not, then the change control process is probably not functioning.  Adding the document revision to the GSPR is, in many instances, just make-work and does not add to the value of the document or the level of compliance.  Being a consultant myself, I know that following a regulation to the letter is the safest solution.  Unfortunately, it is not always the correct solution. So, I am seeking alternative approaches.

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Updating the GSPR checklist to reflect the latest versions of conformity evidence is a task that typically adds a few minutes or less to the product change approval step.  Accordingly, I don't generally buy the notion that updating the GSPR matrix adds significant burden to the product change control process.  If your change control process isn't built to handle that level of change control, then you might consider that there could be a more fundamental problem/deficiency in your change control mechanism.  Indeed, the updating of document revision levels is a fundamental task that already happens pervasively in a change control package.  Updating the GSPR matrix accordingly to reflect these is not a significant burden in a truly transparent, effective, and proper change control mechanism.

Richard and Raje already offered some great typical examples of ways to avoid directly stating the document revision levels in the GSPR matrix.  But I would respectfully contend that those, such as integrating hyperlinks (which will themselves need to be kept up to date), or like omitting evidence revision levels altogether, are comparable in their burden to simply updating the revision level in the matrix.  And those crafty tactics are certainly higher risk.

On that note, as is evident in my many other posts in this Forum, I am certainly an advocate of a risk-based approach wherever appropriate.  Yet see my prior response in this thread for an example of how a prominent regulator (BSI) corporately expects this particular sensitive issue to be directly addressed.  You need to gauge the approach your NB takes when deviating from the letter of the legislation on this particular topic.

Indeed, under the MDD, the requirements for the ER checklist weren't so prescriptively stated, whereas under the EU MDR, the Commission deliberately raised the bar when it legislated that the GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the "precise" identity of the "controlled" documents.  There is a very specific motive behind that amended legislation.  Accordingly, if we simply do it the way we always did it under the MDD, then that undermines the intent of this profound legislative change of the EU MDR.

In light of this, and of the questionable notion that keeping the GSPR matrix updated is somehow overly burdensome as a part of the mechanism (change control) fundamentally intended to assure proper checks and balances, I maintain my prior ultimate advice that you need to proceed cautiously if your GSPR matrix doesn't directly identify the actual data and basis upon which the Article 52 conformity assessment decision was made.

Kevin, I can appreciate your response.  It is technically correct and reflects a strict interpretation of the requirement.  However, I wasn't looking for a strict interpretation of the requirements.  I was looking for a practical and maintainable solution.  In the perfect world, with unlimited resources and ever ending schedules, I would agree that every document revision should be reflected in the GSPR matrix.  However, our world is far from perfect.  Our regulators encourage us to take a risk based approach towards compliance.  Here is a good example of where compliance can be metered by risk.  So, what is the risk of not including document revisions in a GSPR?  I could argue that each revision of a document represents compliance at a point in time.  If I present a GSPR that includes only the document number and then provide the most current version of that document, that represents the current state of compliance.  If it does not, then the change control process is probably not functioning.  Adding the document revision to the GSPR is, in many instances, just make-work and does not add to the value of the document or the level of compliance.  Being a consultant myself, I know that following a regulation to the letter is the safest solution.  Unfortunately, it is not always the correct solution. So, I am seeking alternative approaches.

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Updating the GSPR checklist to reflect the latest versions of conformity evidence is a task that typically adds a few minutes or less to the product change approval step.  Accordingly, I don't generally buy the notion that updating the GSPR matrix adds significant burden to the product change control process.  If your change control process isn't built to handle that level of change control, then you might consider that there could be a more fundamental problem/deficiency in your change control mechanism.  Indeed, the updating of document revision levels is a fundamental task that already happens pervasively in a change control package.  Updating the GSPR matrix accordingly to reflect these is not a significant burden in a truly transparent, effective, and proper change control mechanism.

Richard and Raje already offered some great typical examples of ways to avoid directly stating the document revision levels in the GSPR matrix.  But I would respectfully contend that those, such as integrating hyperlinks (which will themselves need to be kept up to date), or like omitting evidence revision levels altogether, are comparable in their burden to simply updating the revision level in the matrix.  And those crafty tactics are certainly higher risk.

On that note, as is evident in my many other posts in this Forum, I am certainly an advocate of a risk-based approach wherever appropriate.  Yet see my prior response in this thread for an example of how a prominent regulator (BSI) corporately expects this particular sensitive issue to be directly addressed.  You need to gauge the approach your NB takes when deviating from the letter of the legislation on this particular topic.

Indeed, under the MDD, the requirements for the ER checklist weren't so prescriptively stated, whereas under the EU MDR, the Commission deliberately raised the bar when it legislated that the GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the "precise" identity of the "controlled" documents.  There is a very specific motive behind that amended legislation.  Accordingly, if we simply do it the way we always did it under the MDD, then that undermines the intent of this profound legislative change of the EU MDR.

In light of this, and of the questionable notion that keeping the GSPR matrix updated is somehow overly burdensome as a part of the mechanism (change control) fundamentally intended to assure proper checks and balances, I maintain my prior ultimate advice that you need to proceed cautiously if your GSPR matrix doesn't directly identify the actual data and basis upon which the Article 52 conformity assessment decision was made.

Kevin, I can appreciate your response.  It is technically correct and reflects a strict interpretation of the requirement.  However, I wasn't looking for a strict interpretation of the requirements.  I was looking for a practical and maintainable solution.  In the perfect world, with unlimited resources and ever ending schedules, I would agree that every document revision should be reflected in the GSPR matrix.  However, our world is far from perfect.  Our regulators encourage us to take a risk based approach towards compliance.  Here is a good example of where compliance can be metered by risk.  So, what is the risk of not including document revisions in a GSPR?  I could argue that each revision of a document represents compliance at a point in time.  If I present a GSPR that includes only the document number and then provide the most current version of that document, that represents the current state of compliance.  If it does not, then the change control process is probably not functioning.  Adding the document revision to the GSPR is, in many instances, just make-work and does not add to the value of the document or the level of compliance.  Being a consultant myself, I know that following a regulation to the letter is the safest solution.  Unfortunately, it is not always the correct solution. So, I am seeking alternative approaches.

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Kevin, I can appreciate your response.  It is technically correct and reflects a strict interpretation of the requirement.  However, I wasn't looking for a strict interpretation of the requirements.  I was looking for a practical and maintainable solution.  In the perfect world, with unlimited resources and ever ending schedules, I would agree that every document revision should be reflected in the GSPR matrix.  However, our world is far from perfect.  Our regulators encourage us to take a risk based approach towards compliance.  Here is a good example of where compliance can be metered by risk.  So, what is the risk of not including document revisions in a GSPR?  I could argue that each revision of a document represents compliance at a point in time.  If I present a GSPR that includes only the document number and then provide the most current version of that document, that represents the current state of compliance.  If it does not, then the change control process is probably not functioning.  Adding the document revision to the GSPR is, in many instances, just make-work and does not add to the value of the document or the level of compliance.  Being a consultant myself, I know that following a regulation to the letter is the safest solution.  Unfortunately, it is not always the correct solution. So, I am seeking alternative approaches.

The EU MDR requires that GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the precise identity of the controlled documents offering evidence of conformity.  Remember also that the manufacturer shall continuously update the EU declaration of conformity (DoC); those DoC updates are, among other reasons, for assuring that the DoC is always representative of the current latest GSPR evidence on which the Article 52 conformity assessment was based.<o:p></o:p>

<o:p> </o:p>

As an example of these requirements in practice, the Notified Body (NB) BSI has stated that:<o:p></o:p>

<o:p> </o:p>

·         the technical documentation must be updated promptly and as necessary during the lifetime of the device, to ensure it accurately reflects the current status, specification and configuration of the device,<o:p></o:p>

·         the technical documentation needs sufficient detail to allow the NB to fulfil its obligations, and<o:p></o:p>

·         the Annex II technical documentation compilation represents the status of the medical device at a specific moment of its life cycle and should be updated to correspond to the technical documentation.<o:p></o:p>

<o:p> </o:p>

Echoing this, the GHTF (on which whose STED format the EU MDR Annex II Technical Documentation format is based) has advised that the fundamental purpose of the GSPR checklist is for "easy" identification of relevant documents and data, and that the reference to supporting controlled (i.e., revision-controlled) documents should contain the reference to the actual technical documentation that demonstrates conformity to the GSPR, i.e. the actual certificates, actual test reports, actual validation reports, actual study reports, or other actual documents that resulted from the method used to demonstrate conformity. <o:p></o:p>

<o:p> </o:p>

Consequently, if the GSPR checklist only includes generic references (e.g., document titles and numbers) without reference to the corresponding version, then the GSPR checklist doesn't really identify the actual evidence/data on which the conformity assessment and DoC are based.  In a related narrative, BSI has acknowledged that keeping traceability of all of this within the technical documentation, whilst challenging, is essential for demonstrating to CAs/NBs continuous fulfilment of the GSPRs. Accordingly, I would urge caution if your GSPR checklist doesn't identify the applied versions of the supporting evidence.<o:p></o:p>

Hi, GSPR doesnt require the versions /revision updates, you just need documentary evidence to be referenced. If there is change in standards that section needs to be updated.

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Dear Anon

Recommend that you compile a document list with the current document names with their revision numbers. At the beginning of the GSPR, I would add a sentence referring to the Document List (its document name and with its revision number) - a separate document - and state that this Document List lists the current version of each document listed in the GSPR. In the GSPR, I would recommend to list the document title with out the revision number. 

Best Regards,

Stephanie

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Maintaining two redundant lists (a separate list with document revision levels, and then also the list without revision levels in the GSPR matrix) wouldn't be sustainable for me.  It seems that such an approach would demand even more numerous content updates to keep the two lists' items updated plus keeping one of those list's revision levels updated rather than just updating the revision levels in a single list in the GSPR matrix.

Dear Anon

Recommend that you compile a document list with the current document names with their revision numbers. At the beginning of the GSPR, I would add a sentence referring to the Document List (its document name and with its revision number) - a separate document - and state that this Document List lists the current version of each document listed in the GSPR. In the GSPR, I would recommend to list the document title with out the revision number. 

Best Regards,

Stephanie

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Dear Kevin

The Document List is not just required or used for GSPR. 

I know of several firms (small to large size companies) proceeding in this manner.

As well as I have submitting Technical Files this way for the last almost 20 years with no deficiencies from notified bodies. 

Maybe I am missing your point?

Best Regards,

Stephanie

Maintaining two redundant lists (a separate list with document revision levels, and then also the list without revision levels in the GSPR matrix) wouldn't be sustainable for me.  It seems that such an approach would demand even more numerous content updates to keep the two lists' items updated plus keeping one of those list's revision levels updated rather than just updating the revision levels in a single list in the GSPR matrix.

Dear Anon

Recommend that you compile a document list with the current document names with their revision numbers. At the beginning of the GSPR, I would add a sentence referring to the Document List (its document name and with its revision number) - a separate document - and state that this Document List lists the current version of each document listed in the GSPR. In the GSPR, I would recommend to list the document title with out the revision number. 

Best Regards,

Stephanie

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Hi Stephanie,<o:p></o:p>

<o:p> </o:p>

Your fine contributions to this Forum are always appreciated.  For example, your other great post from today regarding the EU MDR transition.<o:p></o:p>

<o:p> </o:p>

The suggestion of maintaining an extra/redundant listing of GSPR evidence documents is certainly another possible way to avoid stating the document revision levels in the GSPR checklist's own required list.  I merely voiced that, for me, such redundancy is not always sustainable, as it can require more documentation and effort than just keeping one single GSPR evidence document list all in one place.  For my clients who have established eQMS systems, such a secondary list is more feasible, though that approach raises its own set of possible pitfalls.  And for my clients who don't yet have eQMS, such a secondary list is generally not an option because of the extra redundancy. Since the purpose of this thread was to find sustainable, efficient ways to deal with Anon's GSPR documentation dilemma, it seems fair for folks to share personal viewpoints about a two-list approach.<o:p></o:p>

<o:p> </o:p>

I would also add that, under the MDD, where little to no legislative mandates were given regarding the specific contents of the ER checklist, I'm sure we all found many creative ways to succeed over the last 20 years of EU compliance careers (for me, almost 30 years).  And under the EU MDR, a two-list approach might be a compliant way to go. But the EU MDR's more prescriptive demand for us to state the "precise" identity of the controlled documents seems to be good grounds for caution about the omission of revision levels from the list of controlled documents in a GSPR checklist.  Indeed, the fundamental purpose of such increased legislation is so that regulators won't need to endure ferreting through too many peripheral documents/steps when vetting the GSPR conformity.  The fundamental goal is for regulators' "easy" identification of GSPR conformity evidence and data.<o:p></o:p>

<o:p> </o:p>

I was also thinking that if we achieve the extra redundant list by way of, let's say, an overall global list (like a master list of all controlled documents, some of which overlap with those needed for GSPR conformity, while many of which will be unrelated to GSPR conformity), then my personal preference would be to avoid that too.  This is because technical documentation reviewers and the EU MDR in this context are only seeking the "easy" and "precise" identity of the controlled documents demonstrating GSPR conformity.  If we force them to slog through a larger repository of documents to identify the ones sought regarding GSPR, then it could trigger objections with respect to the EU MDR's escalated requirement that the GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the "precise" identity of the "controlled" documents.  Giving an EU MDR NB a universal list including out-of-scope documents that don't relate to GSPR conformity evidence may lead to an NB nonconformity regarding the technical documentation or other EU MDR requirements. But as mentioned before, there could be variation in the approach to this depending on the NB involved.<o:p></o:p>

<o:p> </o:p>

On that note, there could also be variation within the same NB.  Specifically, at this time while the NBs are struggling to keep pace and struggling to staff competent technical documentation reviewers, there is more enforcement discretion being employed. But when the NBs catch up, I would view it as a liability if our GSPR checklists identify conformity documents without the revision levels.  Accordingly, I again maintain the aforesaid cautionary advisories regarding this topic.<o:p></o:p>

<o:p> </o:p>

Again, if we do what we've done for our MDD ER checklists for the last 20 years, then, in my humble opinion, such tactics aren't the best approach for this topic due to the EU MDR's aforesaid escalated detailed requirement demanding that an EU MDR GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the "precise" identity of the "controlled" documents.  With the strain on NBs, they are, or will soon be, more sensitive than ever regarding their and the GHTF's intent for "easy" identification of GSPR conformity evidence and data.<o:p></o:p>

Dear Kevin

The Document List is not just required or used for GSPR. 

I know of several firms (small to large size companies) proceeding in this manner.

As well as I have submitting Technical Files this way for the last almost 20 years with no deficiencies from notified bodies. 

Maybe I am missing your point?

Best Regards,

Stephanie

Maintaining two redundant lists (a separate list with document revision levels, and then also the list without revision levels in the GSPR matrix) wouldn't be sustainable for me.  It seems that such an approach would demand even more numerous content updates to keep the two lists' items updated plus keeping one of those list's revision levels updated rather than just updating the revision levels in a single list in the GSPR matrix.

Dear Anon

Recommend that you compile a document list with the current document names with their revision numbers. At the beginning of the GSPR, I would add a sentence referring to the Document List (its document name and with its revision number) - a separate document - and state that this Document List lists the current version of each document listed in the GSPR. In the GSPR, I would recommend to list the document title with out the revision number. 

Best Regards,

Stephanie

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

Dear Kevin

Thanks for your comments.

Just to clarify . 

Only one Document List is compiled which includes Document name, version, etc. There are no duplicate Lists. 

This one Document List needs to be referenced in more than one area in the Technical File. 

There is only one GSPR which references i.e. document names (with out version numbers) which support the fulfilment of each point.

One sentence references the Document List. No duplicate GSPRs or Document Lists.

For several points of the GSPR, the same filename/ file reference needs to be listed.  

If the file gets updated/ revised then the same filename/ file reference listed x times in the GSPR has to be revised then x times.

This process is tedious and prone to error. Yes, I have experience here.

This is the reason why I as well as other firms are using one Document List. 

In a digital age, the one Document List should not be duplicated. Dito GSPR. 

Best Regards,

Stephanie

Hi Stephanie,<o:p></o:p>

<o:p> </o:p>

Your fine contributions to this Forum are always appreciated.  For example, your other great post from today regarding the EU MDR transition.<o:p></o:p>

<o:p> </o:p>

The suggestion of maintaining an extra/redundant listing of GSPR evidence documents is certainly another possible way to avoid stating the document revision levels in the GSPR checklist's own required list.  I merely voiced that, for me, such redundancy is not always sustainable, as it can require more documentation and effort than just keeping one single GSPR evidence document list all in one place.  For my clients who have established eQMS systems, such a secondary list is more feasible, though that approach raises its own set of possible pitfalls.  And for my clients who don't yet have eQMS, such a secondary list is generally not an option because of the extra redundancy. Since the purpose of this thread was to find sustainable, efficient ways to deal with Anon's GSPR documentation dilemma, it seems fair for folks to share personal viewpoints about a two-list approach.<o:p></o:p>

<o:p> </o:p>

I would also add that, under the MDD, where little to no legislative mandates were given regarding the specific contents of the ER checklist, I'm sure we all found many creative ways to succeed over the last 20 years of EU compliance careers (for me, almost 30 years).  And under the EU MDR, a two-list approach might be a compliant way to go. But the EU MDR's more prescriptive demand for us to state the "precise" identity of the controlled documents seems to be good grounds for caution about the omission of revision levels from the list of controlled documents in a GSPR checklist.  Indeed, the fundamental purpose of such increased legislation is so that regulators won't need to endure ferreting through too many peripheral documents/steps when vetting the GSPR conformity.  The fundamental goal is for regulators' "easy" identification of GSPR conformity evidence and data.<o:p></o:p>

<o:p> </o:p>

I was also thinking that if we achieve the extra redundant list by way of, let's say, an overall global list (like a master list of all controlled documents, some of which overlap with those needed for GSPR conformity, while many of which will be unrelated to GSPR conformity), then my personal preference would be to avoid that too.  This is because technical documentation reviewers and the EU MDR in this context are only seeking the "easy" and "precise" identity of the controlled documents demonstrating GSPR conformity.  If we force them to slog through a larger repository of documents to identify the ones sought regarding GSPR, then it could trigger objections with respect to the EU MDR's escalated requirement that the GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the "precise" identity of the "controlled" documents.  Giving an EU MDR NB a universal list including out-of-scope documents that don't relate to GSPR conformity evidence may lead to an NB nonconformity regarding the technical documentation or other EU MDR requirements. But as mentioned before, there could be variation in the approach to this depending on the NB involved.<o:p></o:p>

<o:p> </o:p>

On that note, there could also be variation within the same NB.  Specifically, at this time while the NBs are struggling to keep pace and struggling to staff competent technical documentation reviewers, there is more enforcement discretion being employed. But when the NBs catch up, I would view it as a liability if our GSPR checklists identify conformity documents without the revision levels.  Accordingly, I again maintain the aforesaid cautionary advisories regarding this topic.<o:p></o:p>

<o:p> </o:p>

Again, if we do what we've done for our MDD ER checklists for the last 20 years, then, in my humble opinion, such tactics aren't the best approach for this topic due to the EU MDR's aforesaid escalated detailed requirement demanding that an EU MDR GSPR demonstration of conformity (e.g., the GSPR checklist) shall include the "precise" identity of the "controlled" documents.  With the strain on NBs, they are, or will soon be, more sensitive than ever regarding their and the GHTF's intent for "easy" identification of GSPR conformity evidence and data.<o:p></o:p>

Dear Kevin

The Document List is not just required or used for GSPR. 

I know of several firms (small to large size companies) proceeding in this manner.

As well as I have submitting Technical Files this way for the last almost 20 years with no deficiencies from notified bodies. 

Maybe I am missing your point?

Best Regards,

Stephanie

Maintaining two redundant lists (a separate list with document revision levels, and then also the list without revision levels in the GSPR matrix) wouldn't be sustainable for me.  It seems that such an approach would demand even more numerous content updates to keep the two lists' items updated plus keeping one of those list's revision levels updated rather than just updating the revision levels in a single list in the GSPR matrix.

Dear Anon

Recommend that you compile a document list with the current document names with their revision numbers. At the beginning of the GSPR, I would add a sentence referring to the Document List (its document name and with its revision number) - a separate document - and state that this Document List lists the current version of each document listed in the GSPR. In the GSPR, I would recommend to list the document title with out the revision number. 

Best Regards,

Stephanie

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?  

My product currently has the CE mark according the the MDR.  The GSPR matrix that was prepared includes our internal document references (document numbers) demonstrating conformance to each requirement.  It also inlcudes the document revisions.  I am thinking that it was not appropriate to include the document revisions.  Since receiving the CE mark, there have been many changes to these documents, which result in the GSPR no longer reflects current documentation.  However, all the changes have been insignificant.  My question to the group is whether document revisions are required to be included in the GSPR matrix.  If they are, how do you handle the GSPR when document revisions change?  Do you update it every time with the new revision number?