Per IEC 62304, are DHF documents Configuration Items?

[cwilburn]

Our company provides software development services for medical device manufacturers. We use a configuration management tool for all of our documents, like planing docs, requirements, design, verification docs, etc. I am revising our software configuration management SOP and SCMP template to be compliant with 62304 - are documents considered "configuration items"?

Thanks,
Cathy

 

[yodon]

I say yes.

The definition of a configuration item is: entity that can be uniquely identified at a given reference point

(So no exclusion there). Then 8.1.1 says:

The MANUFACTURER shall establish a scheme for the unique identification of CONFIGURATION ITEMS and their VERSIONS to be controlled for the project. This scheme shall include other SOFTWARE PRODUCTS or entities such as SOUP and documentation. [Class A, B, C]

(Still no exclusion)

And finally, 8.1.3 (note placement under 8.1 Configuration Identification):

8.1.3 Identify SYSTEM configuration documentation
The MANUFACTURER shall document the set of CONFIGURATION ITEMS and their VERSIONS that comprise the SOFTWARE SYSTEM configuration. [Class A, B, C]

(Rather explicit INCLUSION, I'd say.)

That said, documents are generally managed through Doc Control; i.e., not so much under the SCM system. So the point is to ensure proper configuration control over everything that goes into the software system.

 

[glork98]

It depends on how you choose to define it. I'd say "no." The documents that go into the DHF are covered by the general quality system. (That's why they're in the DHF.) Pushing them into the SW CM system will create a redundant storage location.

I'll say this: I've never seen DHF work products placed into the Configuration Management system as part of the quality system. I see people putting informal _copies_ of documents there as it's convenient for SW to do. The docs are released into the DHF and put into electronic, or paper, storage per the corporate policies like docs from all other areas.

Now, there's nothing stopping a company from integrating the SW CM system with the DHF system. It's just electronic storage with version control and handy for all electronic work products. I think that'll become common in the future.

 

[yodon]

It depends on how you choose to define it. I'd say "no." The documents that go into the DHF are covered by the general quality system. (That's why they're in the DHF.) Pushing them into the SW CM system will create a redundant storage location.

Yes, completely agree (I think I said that but probably muddled it up a bit). My point was more that documents are considered to be "configuration items" in the fact that they need to be under configuration / change control but that doesn't imply HOW or WHERE (i.e., doc control is more suitable for documents than a software source code repository).

 

[cwilburn]

We use a configuration management tool to house our DHFs so that is where I believe I was muddling the two. We are a services organization, so we have a separate SCM repository for each client, with separate folders for the DHF, the source code, and other project documents.

What I am concluding is that DHF items need to be controlled, but when listing configuration items (per 62304) for a software system, DHF documents do not need to be listed.

 

[akp060]

Well, the definition of term "Configuration Item" in the standard IEC 62304 is pretty confusing to me. They did not revise it in the 2015 consolidated version. I hope they will revise it next year's edition. The definition has the terms "entity" and "reference point" which are not clear. Is it a reference point in time, or a point on the software system!!

In the definition, the standard makes reference to ISO 12207:2008, clause 4.7. If anyone has access please mention it here

 

[TILL_R]

I'm looking at things from a model-based and system (not only software) development perspective. Why am I saying this?

• model based: we developed a configuration management model that is applied to all artifacts (CIs) that are results of process activities - no matter what the nature; be it a document, a drawing, a product structure node etc.
  all these artifacts are results of value added efforts of a core process (e.g. development process) and should therefore be traceable, especially because they directly relate to the overall result of the core process (e.g. a product).
  The model provides all requirements, attributes, relations and functions that are applied to CIs (e.g. versioning, UID, change control etc.)
• system development: sure, SCM systems have special features and, finally, usually are author-group-specific authoring / team data management tools (TDM = data that can be shared between multiple persons/roles and provides configuration management capabilities).
  However, for systems development, you usually have different TDMs, depending on the disciplines involved: DOORS (RM), Windchill (CAD interface / product structure, drawings), Integrity (software/RM), ... that all together must considered as a configuration management system (or, as we like to call it: Configuration Management Infrastructure)

Having said that, and to come back to the question on what should be considered a CI, it is logical to me to consider any artifact that contributes to traceability of core process activies to be a CI.
Yes, even meeting minutes or mails, if they contain important decisions. (They should usually end up as an attachment of a change request, of course.)​

 

[akp060]

I'm looking at things from a model-based and system (not only software) development perspective. Why am I saying this?

• model based: we developed a configuration management model that is applied to all artifacts (CIs) that are results of process activities - no matter what the nature; be it a document, a drawing, a product structure node etc.
  all these artifacts are results of value added efforts of a core process (e.g. development process) and should therefore be traceable, especially because they directly relate to the overall result of the core process (e.g. a product).
  The model provides all requirements, attributes, relations and functions that are applied to CIs (e.g. versioning, UID, change control etc.)
• system development: sure, SCM systems have special features and, finally, usually are author-group-specific authoring / team data management tools (TDM = data that can be shared between multiple persons/roles and provides configuration management capabilities).
  However, for systems development, you usually have different TDMs, depending on the disciplines involved: DOORS (RM), Windchill (CAD interface / product structure, drawings), Integrity (software/RM), ... that all together must considered as a configuration management system (or, as we like to call it: Configuration Management Infrastructure)

Having said that, and to come back to the question on what should be considered a CI, it is logical to me to consider any artifact that contributes to traceability of core process activies to be a CI.
Yes, even meeting minutes or mails, if they contain important decisions. (They should usually end up as an attachment of a change request, of course.)​

Thank you. This phrase, "that contributes to traceability of core process activities", clarifies CI to me. Is it correct to say that the "reference point" here could be the relevant activities or tasks that generate CI?

 

[TILL_R]

Thank you. This phrase, "that contributes to traceability of core process activities", clarifies CI to me. Is it correct to say that the "reference point" here could be the relevant activities or tasks that generate CI?

I would very much interpret "reference point" like that, yes. A CI itself could be seen as the manifestation/representation of such a reference point.