Community
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Digital Signatures Directly in Vault

Digital Signatures Directly in Vault

There should be a way to create digital signatures from within Vault that would write directly to the drawing files. Currently if I want a "legal" signature I need to print a hard copy to sign which then becomes the legal copy on file (not the DWG) or I need to publish a PDF and use Verisign which then means the PDF becaomes the legal copy.

 

It makes sense to me to have all this done directly from Vault (ideally PLM 360 as well).

 

This is a very important point for regulated industries i.e. FAA, FDA etc.

53 Comments
ihayesjr
Community Manager

@evenmartinsen 

Thank you for posting the idea.

Can you give an example of the workflow you would create to require a signature?

Also, what 3rd party software could be used?

evenmartinsen
Enthusiast
The workflow would be that when performing a state change vault would prompt for username and password. If this does not comply with the user logged in, the workflow would stop. When correct the state change would continue. It would also deny same person to check and approve drawing.

An option for choosing which states requiring this method would also be great. For instance just for approver.

For all purposes i think vault has great possibilities, but lack some


evenmartinsen
Enthusiast

Quote: Also, what 3rd party software could be used?

 

By this i mean that for meeting the reqyirements in FDA regulations for electronic signatures a business needs to make an add-in to Vault in order to fullfill them. 

pgoldenR6CB8
Explorer

Has anyone looked at FDA Title 21 Sec 11 Compliance for Vault? It seems related to this topic.

 

My understanding is that a document produced MAY need to have information like time date user including a watermark to meet FDA requirements.  All this data is captured, but trying to see if any Vault user looked into the Title 21 requirements and specifically tried to meet the signature requirements.  Specifically was looking the ECO process.

 

Trying to see if we can comment on what Vault is capable of vs doing custom development for a prospect.

 

Phil

evenmartinsen
Enthusiast
Extract feom FDA rules:


Electronic Signature Components and Controls. The following electronic signature components and controls are set forth in the regulation (21 CFR 11.200(a),(b)):

* If electronic signatures are not based on biometric identification, they must consist of two distinct components (e.g., an identification code and a password).

For practical reasons this could be a sso number and a password. For all practical reasons Vault is not an "off the shelf" solution for businesses working under FDA regulations. For us we have made an add-in that demands username and password for state changes.
evenmartinsen
Enthusiast

So, now I am testing the setup with a third party add-in that prompts for password on a state change. However, to my surprise, vault does not provide the properties of user and timestamp when you change state.

 

As far as I can see, Vault is not suitable for using in businesses under FDA rules when it comes to audit trail and electronic sugnatures. @ihayesjr 

evenmartinsen
Enthusiast

It should be a fairly easy fix for adesk even without using eco. For each state change it should be called for username and password. A property containing username and timestamp should be saved on that revision and the fda demand is fullfilled. 

ihayesjr
Community Manager

@evenmartinsen 

We currently use the "Latest Approver" and "Latest Released Date" which record the user and date the file went into the Release state. Although it does not prompt for username and password, have you looked at these properties and mapped them to a file property?

evenmartinsen
Enthusiast

Yes. However there is some limitations of using latest approver. If this is used as a property in the revision table, when creating a new revision the table has already filled it with the latest approver for the earlier revision. It is therefore not suitable for use on the drawing. You cannot have a drawing in WIP where the revision table shows latest approver and date, since this revision has not been approved. 

 

My suggestion: when changing states, the person and time should be saved to a property, for use in the revision table. 

 

It should not be linked to last modified, or checked in by.  Only to who and when the state change was made. 

ihayesjr
Community Manager

A Custom property would have the same issue. Someone will have to manually delete the value in the property for the next revision.

evenmartinsen
Enthusiast
Most likely. However, this would be a programming issue. I would assume that an option like, when setting up lifecycles, for certain transitions you could choose that the property should be blanked.

Concerning this, but also the revision table / revision workflow i cannot see how companies benefit of it. And if we have learned something these last couple of years is that electronic signatures / digital signatures is very useful. And its a pity that from going from a paper system to a electronic system that should be one of the best, and cost an arm and a leg, does not provide this. Yes it provides the Latest approver, but it does not take into the account the checked by and issued by.
ihayesjr
Community Manager

Can you comment on the following?

  • Issued by - the person who created the drawing or the last person who edited the drawing while it is in Work in Progress?
  • Checked by or Approver - the person who looked at the drawing in the Review state and moved it from the Review state to the Released state

Are these correct?

 

evenmartinsen
Enthusiast
The drafter sets the drawimg to for review when the drawing is finished. The engineer sets the drawing to reviewed. The responsible engineer approve/release the drawing.

In some cases there may also be a person from HSE that also shall check the drawing.
Telson.HADDEN4HGWS
Contributor

It would have to be configurable, but those are valid default settings, @ihayesjr 

 

We have 4(5, really) states here - with signatures entered manually in a custom iProperty, which is not ideal:

1. WIP - no signature

2. Peer Review - now signed by the person who moved it from WIP to Peer Review 

3. Design Review - now signed by the peer reviewer

4. Sent for Approval - now signed by design authority

5. Approved - now signed by final authority

 

There would ideally be a NEW set of write once properties created, maybe an array of signatures for each revision, different organizations are going to have different numbers of signatures required; there may even be more or fewer based on file type.

 

In the example above you would have

Rev(0),Sig(0)=#2 above

Rev(0),Sig(1)=#3

Rev(0),Sig(2)=#4

Rev(0),Sig(3)=#5

 

The signatures for revision 0 remain the same people, even if new people are signing off on revision 1.  There needs to be an accessible history, that we can display in properties on the drawing.

 

So when revised you would get new properties:

Rev(1),Sig(0)=New #2

Rev(1),Sig(1)=New #3

Rev(1),Sig(2)=New #4

Rev(1),Sig(3)=New #5

 

This way, you could always access who signed at what revision level.  Hope that makes sense.

ihayesjr
Community Manager

@Telson.HADDEN4HGWS 

Using your example would this work?

User-defined Properties

  • Designed by
  • Peer Reviewed by
  • Design Reviewed by
  • Approved by

Rev 0 of model

  1. PersonA moves the model from WIP -> Peer Review. Property "Designed by" = PersonA
  2. PersonB moves the model from Peer Review -> Design Review. Property "Peer Reviewed by" = PersonB
  3. PersonC moves the model from Design Review -> Approval. Property "Design Reviewed by" = PersonC
  4. PersonD moves the model from Approval -> Released. Property "Approved by" = Person D

The model gets moved from Released -> WIP.

  • Revision gets bumped to "1"
  • All properties above get emptied.

Is this correct?

Telson.HADDEN4HGWS
Contributor

@ihayesjr 

We still need a record of who signed off on rev 0, so not exactly.

Revision 1 would have a whole new set of properties for signatures - but the name of the property wouldn't change, just the index. It would have to be a different kind of property, represented by an array variable internally, and we would address it by <name(revision)>.  The user-facing part of it would be a little tricky, but I think it's doable.

ihayesjr
Community Manager

@Telson.HADDEN4HGWS 

Rev 0's record will still have that data. It isn't required to have a new set of properties for each revision.

ihayesjr
Community Manager

For example, if you put this information in the Revision table, Rev 0 will still show that PersonD approved the model while the model has transitioned to Rev 1.

Telson.HADDEN4HGWS
Contributor

@ihayesjr I disagree - we have the record of the original signatories on EVERY revision of the drawing, Rev 1 drawing has a record of the signer's of rev 0, and revision 1 in the rev block has the signatures of the rev 1 people. This is a regulatory requirement in our industry. 😕

Telson.HADDEN4HGWS
Contributor

Now - we do something very much like what you are describing, but it could be better.

We have those 4 properties, plus 4 more with "rev_" in front of the name, and the current revision signatures go in there, so they can be displayed on the drawing.

Can't find what you're looking for? Ask the community or share your knowledge.

Submit Idea  

Autodesk Design & Make Report