CDA R3 Support non-verification signatures

Return to SDTC page; Return to CDA R3 Formal Proposals page.

Submitted by: Calvin E. Beebe	Revision date: Sept. 14, 2009
Submitted date: Sept. 14, 2009	Change request ID: <<Change Request ID>>

Issue

Currently CDA R2 supports signature meta-data in the header for Authenticator and Legal Authenticator participations. The signatures associated with these verification participations, are typical in medical records for provider created documents, however there are some use cases where the signature is needed on other participations.

When a patient or guardian signs a consent or authorization document, they are not verifying to the completeness and accuracy of the document, but rather agreeing to the terms and conditions defined in the document. Thus the “agreement to terms” by patient or guardian, is signified by their signature on the document.

Recommendation

• I would recommend that signature information be captured in CDA documents for patient and / or guardians. In that way, signatures indicating consent and agreement to authorizations could be captured in the document header meta-data.
• I would enable support for effective time - end date on signatures related to authorizations, so that authorizations that expire after a given date, could be captured in the header meta-data.
• Consider additional support for signatures by reviewers of a document, or witnesses to an act or signing. Currently the witness participations can not take a signature and the reviewer participation is not possible as there is no participation type code supporting it.

Rationale

Not all signatures on clinical documents are verification signatures. The CDA does not seem to support the concept of signing a document to indicate agreement to terms and conditions, to indicate reviewed and considered or witnessed by. The agreement to terms and conditions are common in authorizations and consents and at a minimum needs to be supported.

Resolution

March 30, 2010 SDWG: Agree that there are cases where the signing use case may need to be clarified. Examples as above. Whether this is via participantType, within W3C signature block, via IHE DSig profile, etc, will need to be worked out. opposed: 0; abstain: 0: approve: 6.