CDAR2_IG_DIGITALSIG_R1_TBD_V3
HL7 Implementation Guide for CDA® Release 2: Digital
Signatures and Delegation of Rights,
Release 1
July 2013
HL7 DSTU Ballot
Sponsored by:
Structured Documentation Work Group
Attachments Work Group
Security Work Group
Acknowledgements and Copyrights
Copyright © 2013 Health Level Seven International ® ALL RIGHTS RESERVED. The reproduction of this
material in any form is strictly forbidden without the written permission of the publisher. HL7 and Health
Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of this material is governed by HL7's IP Compliance Policy.
This material includes information from a number of sources…
[cite all sources, W3C, OASIS, et al]
Page ii
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
TABLE OF CONTENTS
1
INTRODUCTION ............................................................................................................................ 6
1.1 PURPOSE ................................................................................................................................................... 6
1.2 AUDIENCE .................................................................................................................................................. 6
1.2.1
RELEVANT DOCUMENTATION ............................................................................................................... 6
1.2.2
REQUISITE KNOWLEDGE...................................................................................................................... 7
1.3 ORGANIZATION OF THIS GUIDE .................................................................................................................... 7
1.3.1
CONVENTIONS .................................................................................................................................... 7
1.3.2
CONFORMANCE CONVENTIONS ......................................................... ERROR! BOOKMARK NOT DEFINED.
1.3.3
KEYWORDS ........................................................................................................................................ 7
1.4 BUSINESS NEEDS SUPPORTED .................................................................................................................... 9
1.5 ASSUMPTIONS ............................................................................................................................................ 9
1.6 IN-SCOPE ................................................................................................................................................. 10
1.7 OUT OF SCOPE ......................................................................................................................................... 10
2
DATASET REQUIREMENTS .......................................................................................................... 11
2.1 SIGNING CERTIFICATE INFORMATION ......................................................................................................... 11
2.2 DELEGATION OF RIGHTS ASSERTION ......................................................................................................... 11
2.3 VALIDATED DELEGATION OF RIGHTS ASSERTION ........................................................................................ 12
2.4 DOCUMENT SIGNATURE (XADES-X-L ELEMENTS)...................................................................................... 12
2.5 CODE SETS .............................................................................................................................................. 15
3
SCENARIO (USER STORY) .......................................................................................................... 16
3.1 USER STORY ............................................................................................................................................ 16
3.2 ACTIVITY DIAGRAM ................................................................................................................................... 16
3.3 BASE FLOW .............................................................................................................................................. 18
3.4 FUNCTIONAL REQUIREMENTS .................................................................................................................... 20
3.4.1
INFORMATION INTERCHANGE REQUIREMENTS..................................................................................... 20
3.4.2
SYSTEM REQUIREMENTS ................................................................................................................... 21
3.5 SEQUENCE DIAGRAM ................................................................................................................................ 22
4
5
VERIFICATION OF X.509V3 PUBLIC DIGITAL CERTIFICATE ............................................................ 23
DIGITAL SIGNATURE PROCESS ................................................................................................... 24
5.1 PRE-CONDITIONS ..................................................................................................................................... 24
5.2 SIGNATURE PROCESS ............................................................................................................................... 24
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
Page iii
July 2013
TABLE OF CONTENTS
5.3 VERIFICATION PROCESS FOR SIGNATURE .................................................................................................. 24
6
DIGITAL SIGNATURE STANDARD ................................................................................................. 25
6.1 ISSUING AN XADES-BASED SIGNATURE ..................................................................................................... 25
6.2 PROCESSING AN XADES-BASED BASED SIGNATURE................................................................................... 25
7
DELEGATION OF RIGHTS PROCESS ............................................................................................. 26
7.1 OVERVIEW OF THE DELEGATION OF RIGHTS PROCESS ............................................................................... 26
7.2 PRE-CONDITIONS ..................................................................................................................................... 27
7.3 PROCESS TO ISSUE DELEGATION OF RIGHTS ARTIFACT .............................................................................. 28
7.4 VERIFICATION OF DELEGATION OF RIGHTS ARTIFACT.................................................................................. 28
7.5 PROCESS TO ISSUE DELEGATION AGENT SIGNATURE ................................................................................. 28
7.6 VERIFICATION OF DELEGATION AGENT SIGNATURE..................................................................................... 28
7.7 DELEGATION OF RIGHTS CHAINING ............................................................................................................ 29
8
DELEGATION OF RIGHTS STANDARD ........................................................................................... 30
8.1 ISSUING A SAML BASED DELEGATION OF RIGHTS ARTIFACT ....................................................................... 30
8.1.1
PROCESSING A SAML BASED DELEGATION OF RIGHTS ARTIFACT ....................................................... 31
8.2 ISSUING A DELEGATION AGENT SIGNATURE ............................................................................................... 31
8.2.1
PROCESSING ADELEGATION AGENT SIGNATURE................................................................................. 32
9 INCORPORATING ARTIFACTS INTO A CDA DOCUMENT ................................................................. 33
10 APPENDIX A: EXAMPLE.............................................................................................................. 34
10.1 XADES-X-L DIGITAL SIGNATURE .............................................................................................................. 34
10.2 SAML DELEGATION OF RIGHTS ARTIFACT ................................................................................................. 34
10.3 XADES-X-L DIGITAL SIGNATURE APPLIED TO SAML DELEGATION OF RIGHTS ............................................ 34
Page iv
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
INDEX OF TABLES
TABLE 2-1. SIGNING CERTIFICATE INFORMATION ............................................................................................................... 11
TABLE 2-2. DELEGATION OF RIGHTS ASSERTION ............................................................................................................... 11
TABLE 2-3. VALIDATED DELEGATION OF RIGHTS ASSERTION ................................................................................................ 12
TABLE 2-4. DOCUMENT SIGNATURE .............................................................................................................................. 12
TABLE 2-5. CODE SETS ............................................................................................................................................. 15
TABLE 3-1. BASE FLOW............................................................................................................................................. 18
TABLE 3-2. INFORMATION INTERCHANGE REQUIREMENTS .................................................................................................... 20
TABLE 3-3. SYSTEM REQUIREMENTS ............................................................................................................................. 21
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page v
July 2013
© 2013 Health Level Seven International. All rights reserved.
1 INTRODUCTION
The HL7 Implementation Guide for CDA Release 2: Digital Signatures and Delegation of Rights, Release 1 is a
collaboration between HL7 and the Centers for Medicare & Medicaid Services (CMS) Electronic Submission
of Medical Documentation (esMD) Initiative. This implementation guide defines a means to attach digital
signatures to a CDA document, as well as provide a method of specifying delegation of right assertions.
1.1
Purpose
The esMD Initiative provides solutions that address gaps identified by CMS post-payment reviews. Through
the participation of additional stakeholders, the outputs of the initiative have expanded to reflect the
requirements of other payers, providers, and stakeholders. The esMD Initiative focuses on identifying the
requirements, core data sets, and standards to support specific use cases, including Provider Registration
with a Payer to receive Electronic Medical Documentation Requests (eMDRs)1, the secure sending of eMDRs
from the Payer to the registered provider, and the application of digital signatures on CDA documents.
This solution will allow CMS, other health plans, payers, and providers to accurately authenticate the author
of individual documents within the medical record, and trust the validity and authenticity of submitted
medical documentation. Examples in this guide focus on the use of digitally-signed documents and
delegation of right assertions within a CDA document for administrative purposes. However, the use of
signed documents and delegation of right assertions is not limited to administrative use cases, thus, the
processes in this guide are meant to be applicable to other uses.
1.2
Audience
This guide is intended to assist providers, agents2, payers, review contractors, and any other health care
organization that wants to apply digital signatures to a CDA document.
There are three primary audiences for this guide:
1. Providers and Payers that wish to apply digital signatures to a CDA document
2. Providers that wish to submit digitially-signed medical documentation for administrative purposes
3. Payers that wish to process digitally-signed medical documentation sent by a provider
The secondary audience for this document includes:
1. Software developers that may develop products to assist payers, providers, and their agents in
applying digital signatures to a CDA document.
1.2.1
RELEVANT DOCUMENTATION
List any relevant HL7 or other specifications or documents here.
1 eMDR
– Electronic Medical Documentation Request refers to a request sent electronically from a Payer or Payer Contractor
Agent - Regional Health Information Organizations (RHIO), Health Information Exchanges (HIE), Release of Information (ROI) vendors, claim
clearinghouses, and other entities that handle health information on behalf of a Provider under a Business Associate Agreement (BAA).
2
Page 6
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
1.2.2
REQUISITE KNOWLEDGE
Participants have prior knowledge of the XML Digital Signature (XML-DSIG) and XML Advanced Electronic
Signatures (XAdES) standards, which specify the use of XML based digital signatures.
Participants have prior knowledge of the OASIS Security Assertion Markup Language (SAML) standard, which
specifies a data format for exchanging authentication and authorization data between parties, used in this
guide to convey the delegation of rights assertion.
Participants have prior knowledge of the HL7 Reference Implementation Model (RIM) and Clinical Document
Architecture (CDA) format (R2). The RIM is an object model standard for the HL7 clinical data structures and
domains (including CDA). CDA is an XML-based markup standard intended to specify the encoding, structure
and semantics of clinical documents for exchange.
1.3
1.3.1
Organization of This Guide
CONVENTIONS
This guide adheres to the following conventions:

Add conventions that readers should be aware of, e.g.,

Text formatted as monoSpacedCamelCase indicates a literal data element representation from an
underlying standard and the definition is bound to that standard.

The use of the term “signer” indicates the entity that has applied a Digital Signature to a CDA document
as described in this implementation guide. All other participants who may otherwise sign a document
are out of scope.
1.3.2
KEYWORDS
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC
21193. The following definitions are excerpted from the RFC:
MUST or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the
specification.
MUST NOT or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the
specification.
SHOULD or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular
circumstances to ignore a particular item, but the full implications must be understood and carefully
weighed before choosing a different course.
SHOULD NOT or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in
particular circumstances when the particular behavior is acceptable or even useful, but the full
3
http://www.ietf.org/rfc/rfc2119.txt
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 7
July 2013
© 2013 Health Level Seven International. All rights reserved.
implications should be understood and the case carefully weighed before implementing any behavior
described with this label.
MAY or the adjective "OPTIONAL", mean that an item is truly optional. One software supplier may
choose to include the item to enable certain capabilities while another software supplier may omit the
same item. In either case, the communication partner cannot be expected to either provide it (sender)
or process it (receiver) without clear and voluntary agreement between the partners.
An implementation which does not include items marked as optional MUST be prepared to interoperate
with another implementation which does include the optional item, but is not obligated to support the
optional item. In the same vein an implementation that includes a particular item marked as optional MUST
be prepared to interoperate with other implementations which do not support the optional item.
Page 8
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
2 USE CASES
This document provides guidance on the use of digital signatures on a CDA document to perform the
following actions:


Determine in a non-repudiation method the action, role, and contribution of each participant with
respect to medical documentation in support of claims for payment for services delivered by
providers.
Provide delegation of rights where the signer is not the responsible individual or organization (e.g.,
the signer is acting as an authorized agent).
It is intended to:




Identify a digital signature standard for a CDA document that supports the exchange of:
o A signed:
 Digest of the message
 Timestamp
 Purpose of signature
o The public certificate of the signer
o Long term validation data, including Online Certificate Status Protocol (OCSP) response
and/or Certificate Revocation List (CRL)
Identify a standard to assert a delegation of rights that supports the exchange of:
o The certificate ID of both parties
o The purpose of the delegation
o The effective date range of the assertion
Identify a method to validate an existing delegation of rights assertion.
Identify a method of incorporating digital signatures and delegation of right assertions into the
header of a CDA document.
The immediate need to provide digital signatures and delegation of rights assertion artifacts can be met with
existing standards. The capability may be provided as a service by third parties or incorporated directly into
or provided in conjunction with EHRs and payer systems. A method to support validation of an existing
delegation of rights assertion is presented in this guide.
2.1
2.2


Assumptions
All Payer Entities and Provider Entities must obtain a Digital Identity from a recognized Certificate
Authority (e.g., in the United States, from a Federal Bridge cross-certified CA).
Certificate Authorities exist and are capable of providing the necessary digital credentials for signing.
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 9
July 2013
© 2013 Health Level Seven International. All rights reserved.





2.3






2.4







Technology exists to utilize the digital credentials for signing a CDA document.
The signature on a document attests to the signer’s role and the accuracy of the signed
documentation for which they are responsible.
Documents supporting services delivered should be digitally signed with the date/time and action
(e.g., creation, review, etc) at the time the action is performed or, at a minimum, prior to the time
required by the relative administrative use. These signed documents should be maintained for the
time required by the payer’s retention policy. The specific policies for payers should be followed for
services covered by each payer.
Document revision or addendum should be signed at the time the revisions or addenda are
completed, indicating the appropriate action(s). Requirement to maintain antecedent signed
documents should be based on medical legal documentation requirements (e.g. CMS Medicare
Program Integrity Manual Chapter 3) and industry best practice.
If multiple signed CDA documents are required to meet documentation requirements for a patient
encounter, they will be maintained in a way that permits submission of all related documents for a
defined administrative purpose.
In-Scope
Solutions for individual or organizational digital signatures for discrete CDA Documents to attest to
the validity and authenticity of the information within the Document or actions performed on the
Document
Signing activities include, but are not limited to: creation, modification, approval, and review
Persistence of Digital Signature and Delegation of Rights artifacts
Defining delegation of rights between the signer and the authorized individual
Validation of signature artifacts and delegation of rights assertion(s) by recipient
Creation of the digital signature artifact and the delegation of rights assertion by the signer
Out of Scope
Transport and message standards for the exchange of signed CDAs
Encryption of CDAs for security or privacy
A definition of electronic transactions between RA and CA
A definition of electronic transactions between Payer Entity and RA or CA
A definition of electronic transactions between Provider Entity and RA or CA
Consent, privacy, and use of the signed CDA document in situations other than providing
documentation to payers for the sake of program or benefits administration
Signature by patient or their authorized representative
Page 10
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
3 DATASET REQUIREMENTS
This table lists the data elements and data element sets that will be available within the certificate
information, document signature, and delegation of rights assertion of the CDA document. Each data
element listed below is necessary for some aspect of the Use Case; however, the table does not specify
exactly how they may be used together.
3.1
Signing Certificate Information
Table 3-1. Signing Certificate Information
Data Element
Repeat Data Element Description
Additional Notes
Version
N
Version of X.509
Serial Number
N
Unique Serial Number of Certificate from the CA
Algorithm ID
N
Algorithm used by the CA to sign the certificate
Issuer
N
Name of CA that issued certificate
Validity
N
Period of time for which the certificate is valid
Subject
N
Subject Name -- Name of whom the certificate is
issued to
Subject Public Key Info
N
The subject’s public key
Issuer Unique Identifier
N
Subject Unique Identifier
N
NPI or Alternate Payer ID
For billing entities only
Extensions
Y
Describes specific purpose of use, values, and
critical or non-critical identifier
Object Identifier for each extension; this
is where the non-repudiation “flag” is
located (which must be set)
Certificate Signature
Algorithm
N
Algorithm used to sign the certificate
Certificate Signature
N
3.2
All must be version 3 or later (X.509v3+)
Not Before, Not After
Delegation of Rights Assertion
Table 3-2. Delegation of Rights Assertion
Data Element
Repeat Data Element Description
Additional Notes
Public Digital certificate of
assertion signer
?
X.509v3+ Token Profile
Signed by trust authority, certificates must be issued
by authorities cross- certified with the Federal Bridge
Signature Artifact
?
Signature Artifact encrypted by
signer’s private key
At a minimum the Signature Artifact will include the
digest (hash) of the Delegation of Rights Assertion
Delegation of Rights
?
Assertion for the Delegation of
Rights
At a minimum the Delegation of Rights must include
the CA and Serial Number of the Delegatee Signing
Digital Certificate, the effective date range of the
Delegation of Rights, and the rights granted
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 11
July 2013
© 2013 Health Level Seven International. All rights reserved.
3.3
Validated Delegation of Rights Assertion
Table 3-3. Validated Delegation of Rights Assertion
Data Element
Repeat Data Element Description Additional Notes
Public Digital
certificate of Validation
Server
?
X.509v3+ Token Profile
Signature Artifact
?
Signature Artifact encrypted At a minimum the Signature Artifact will include the digest (hash)
by signer’s private key
of the Signature Artifact and Delegation of Rights Assertion
below
Public Digital
certificate of assertion
signer
?
X.509v3+ Token Profile
Signature Artifact
?
Signature Artifact encrypted At a minimum the Signature Artifact will include the digest (hash)
by signer’s private key
of the Delegation of Rights Assertion
Delegation of Rights
?
Assertion for the Delegation At a minimum the Delegation of Rights must include the CA and
of Rights
Serial Number of the Delegatee Signing Digital Certificate, the
effective date range of the Delegation of Rights, and the rights
granted
3.4
Signed by trust authority, certificates must be issued by
authorities cross- certified with the Federal Bridge
Signed by trust authority, certificates must be issued by
authorities cross- certified with the Federal Bridge
Document Signature (XAdES-X-L Elements)
Table 3-4. Document Signature
Data Element
Repeat Data Element Description
CanonicalizationMetho
d
Indicates method used for canonicalizing
XML node sets resulting after retrieving
(and processing when required) the data
objects covered by the time-stamp
token(s)
SignatureMethod
Constant value:
http://www.w3.org/2000/09/xmldsig#rsasha1
DigestMethod
Method used to create digest. Constant
value:
http://www.w3.org/2000/09/xmldsig#sha1
KeyInfo
Public key information for validating
signatures
X509Certificate
The actual X.509v3 certificate of the
signers, with the public key. This is
required for archival validation.
SignatureProperties
Contains the extended properties of the
signature.
Manifest
A list of one or more document reference
URIs and digest values to which the
signature applies
QualifyingProperties
Acts as a container element for all the
Additional Notes
When not present, the standard canonicalization
method as specified by XML-DSIG MUST be used
ID “purposeOfSignature” is a coded value for the
purpose of the signature as defined in ASTM E1762-05
Page 12
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
Table 3-4. Document Signature
Data Element
Repeat Data Element Description
Additional Notes
qualifying information that should be
added to an XML signature.
Target attribute
Must refer to the ID attribute of the
corresponding ds:Signature. Its value
MUST be an URI with a bare-name
XPointer fragment.
ID attribute
Can be used to make a reference to the
QualifyingProperties container
SignedProperties
Properties that are cryptographically
bound (i.e., signed) to the XML signature
SignedSignaturePrope
rties
Contains properties that qualify the XML
signature that has been specified with the
Target attribute of the QualifyingProperties
container element.
When this element is enveloped by the XAdES
signature, its not-fragment part MUST be empty.
Otherwise, its not-fragment part MAY NOT be
empty
SigningTime
N
Specifies the time at which the signer
(purportedly) performed the signing
process.
SigningCertificate
N
Contains references to certificates and
digest values computed on them. The
certificate used to verify the signature
SHALL be identified in the sequence.
The signature policy MAY mandate other
certificates be present, that MAY include all the
certificates up to the point of trust.
IssuerSerial
Contains the identifier of one of the
certificates referenced in the sequence.
Should the ds:X509IssuerSerial element
appear in the signature to denote the
same certificate.
Its value MUST be consistent with the
corresponding IssuerSerial element.
CertDigest
Contains the digest of one of the
certificates referenced in the sequence.
It contains two elements: ds:DigestMethod
indicates the digest algorithm and ds:DigestValue
contains the base-64 encoded value of the digest
computed on the DER-encoded certificate.
SignaturePolicyIdentifi
er
N
A signed property qualifying the signature. If there is not a specific signing policy to refer to in
the schema, then devices that comply with this
profile comply with
‘IHEITIDigitalSignatureContentProfile.’
SigPolicyHash
Contains the identifier of the hash
algorithm and the hash value of the
signature policy.
SigPolicyQualifier
Can contain additional information
qualifying the signature policy identifier.
SignatureProductionPl
ace
Specifies an address associated with the
signer at a particular geographical (e.g.
city) location.
SignerRole
N
The optional ds:Transforms element can contain
the transformations performed on the signature
policy document before computing its hash.
Property that contains a sequence of roles At least one of the two elements must be present:
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 13
July 2013
© 2013 Health Level Seven International. All rights reserved.
Table 3-4. Document Signature
Data Element
Repeat Data Element Description
Additional Notes
that the signer can play (element
SignerRole).
ClaimedRoles, CertifiedRoles
ClaimedRoles
Contains a sequence of roles claimed by
the signer but not certified. Additional
contents types MAY be defined on a
domain application basis and be part of
this element.
The namespaces given to the corresponding XML
schemas will allow their unambiguous
identification in the case these roles use XML.
CertifiedRoles
Contains the encoding of one or more
DER-encoded attribute certificates for the
signer.
SignedDataObjectProp
erties
Element that contains properties that
qualify some of the signed data objects.
ObjectReference
An attribute that MUST reference the
ds:Reference element of the ds:Signature
corresponding with the data object
qualified by this property.
CommittmentTypeQUa
lifiers
Element that provides means to include
additional qualifying information on the
commitment made by the signer.
AllDataObjectsTimeSta
mp
Contains the time-stamp computed before
the signature production, over the
sequence formed by ALL the ds:Reference
elements within the ds:SignedInfo
referencing whatever the signer wants to
sign except the SignedProperties element.
UnsignedProperties
Properties that are not bound/signed
UnsignedSignaturePro
perties
Elements contains properties that qualify
the XML signature that has been specified
with the Target attribute of the
QualifyingProperties container element.
CounterSignature
Qualifies the signature. The ds:SignedInfo
MUST contain one ds:Reference element
referencing the ds:SignatureValue element
of the embedding and countersigned
XAdES signature.
SignatureTimeStamp
A container for a time-stamp token over
the SignatureValue element to protect
against repudiation in case of a key
compromise.
The content of the ds:DigestValue in the
aforementioned ds:Reference element of the
countersignature MUST be the base-64 encoded
digest of the complete (and canonicalized)
ds:SignatureValue element (i.e. including the
starting and closing tags) of the embedding and
countersigned XAdES signature. A
countersignature MAY itself be qualified by a
CounterSignature property, which will have a
ds:Reference element referencing the
ds:SignatureValue of the first countersignature.
Page 14
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
Table 3-4. Document Signature
Data Element
3.5
Repeat Data Element Description
Additional Notes
Code Sets
Table 3-5. Code Sets
Data Element
Document Action
Repeat
Y
Data Element Description
Additional Notes
Action performed on document
Needs code table (see XAdES)
Create
author
Modify
Author of changes
Read
Attesting to the review of the signed document
Delegation of Rights
Assertion Action
Y
Action performed on the
Delegation of Rights Assertion
Needs code table
?
?
Validation
Delegation of Rights Assertion is valid as of the time stamp
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 15
July 2013
© 2013 Health Level Seven International. All rights reserved.
4 SCENARIO (USER STORY)
A Provider Entity or its delegated agent must attest to actions taken (e.g. creation, modification, review)
with respect to a specific CDA document at the time the action is taken/completed. This attestation must be
non-repudiable and verifiable by a third party from the artifacts created at the time of signing. The Provider
Entity or its delegated agent has a need to send the CDA document to a third party accompanied by the
attestation and, where necessary, the proof of delegation.
4.1
User Story
In order to participate in digital signing, the Provider Entity and any delegated agent must obtain and
maintain a non-repudiation digital identity. Both actors initiate the process to obtain an X.509v3 digital
signing certificate.4 . Entities approved by a Registration authority will receive Credentials from a Certificate
Authority to incorporate into their business process.
If required, the Provider Entity creates and digitally signs a Delegation of Rights assertion to permit a
delegated agent to sign a CDA document on their behalf. It is the responsibility of the Provider Entity to
ensure that the Delegation of Rights is validated with each signature.When a Provider Entity or their
delegated agent completes an attestable action with respect to a CDA document, the Provider Entity or
delegated agent will create a digital signature artifact attesting to the date/time and action taken by
encrypting a digest of the CDA document, the date/time, and action code with the private key of signing
digital certificate.
The Provider Entity, who has satisfied any payer registration that may be required for a specific exchange of
documentation with a payer, sends (directly or through a delegated agent) the CDA document with the
included digital signature artifacts and any delegation of rights artifacts in a secure transaction to the payer
using appropriate transmission methods.Upon receiving the digitally signed CDA document with digital
signature and delegation of rights artifacts, the Payer Entity validates the following: each Digital Certificate
and its chain to the appropriate Certificate Policy (CP), delegation of rights artifacts where required, and
digital signature artifact. Additionally, the Payer Entity decrypts the hash of the CDA document and validates
data integrity of the CDA document received. (Note - The Payer Entity does not validate the accuracy of the
contents of the Documentation received as part of determining the document integrity.) Any responses to
the sending Provider Entity regarding success or failure of validation of the digital signature, delegation of
rights, and integrity of the document shall be defined in the specific esMD use case.
4.2
Activity Diagram
The Activity Diagram illustrates the use case flows graphically and represents the flow of events and
information between the actors. It also displays the main events/actions that are required for the data
exchange and the role of each system in supporting the exchange.
4
In the United States, the X.509v3 digital signing certificate must come from a Federal Bridge cross-certified Certificate Authority.
Page 16
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
Payer Entity
Information System
Provider Entity
Information System
Delegatee
Information System
1A. Provider Entity
requests Digital
Identity from
Registration
Authority
1B. Non-Provider
Delegatee requests
Digital Identity from
Registration
Authority
4A. Provider Entity
obtains and
incorporates Digital
Certificate/
Credentials into its
business process
4B. Non-Provider
Delegatee obtains
and incorporates
Digital Certificate/
Credentials into its
business process
Registration Authority
Information System
Certificate Authority
Information System
2. Registration
Authority approves
(or rejects) the
request for Identity
Proofing and upon
approval sends
information to
Certificate Authority
3. Certificate Authority
generates the Digital
Certificate/Credentials
and informs the Provider
Entity / Non-Provider
Delegatee of their
availability
5. Provider Entity
creates Delegation
of Rights Assertion
6A. Provider Entity
completes action on
a document and
digitally signs
document
6C. Provider Entity
system validates
and signs
Delegation of
Rights Assertion
and makes
available to
Delegatee
8. Payer Entity
receives Signed
Document
authenticates Digital
Certificates,
Signature Artifact
and, where
necessary,
Delegation of Rights
Assertion, and
validates data
integrity of
Document.
7A. Provider Entity
sends signed
document to Payer
Entity
6B. Delegatee
completes action on
document on behalf
of Provider Entity
and digitally signs
document amd
requests validated
Delegation of
Rights
6D. Delegatee
attaches validated
Delegation of
Rights Assertion to
signed document
7B. Delegatee
sends signed
document and
signed Delgation of
Rights Assertion to
Payer Entity
Key
= Asynchronous
FIGURE 1: ACTIVITY DIAGRAM
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 17
July 2013
© 2013 Health Level Seven International. All rights reserved.
Notes:
1.
The following are alternative paths (1A/1B, 4A/4B, 6A/6B+6C+6D, and 7A/7B)
2.
Activities related to Delegatee (1B, 4B, 5, 6B, 6C, 6D, and 7B) occur only if the is a need for a
Delegation of Rights
4.3
Base Flow
The Base Flow presents the step by step process of the information exchange depicted in the activity
diagram (above). It indicates the actor who performs the action, the description of the event/action, and the
associated inputs (records/data required to undertake the action) and outputs (records/data produced by
actions taken).
Table 4-1. Base Flow
Step Actor
Role
Event/Description
Inputs
Outputs
1A Provider Entity Requests Digital Provider Entity requests
Identity
Digital Identity from
Registration Authority
Provider Entity
need for Digital
Identity
Relevant Provider Interoperability
Entity identification
information
1B Non-Provider
Delegatee
Requests Digital Non-Provider Delegatee
Identity
requests Digital Identity
from Registration
Authority
Interoperability
Non-Provider
Relevant NonDelegatee need Provider Delegatee
for Digital Identity identification
information
2
Registration
Authority
Validates
Identity
Registration Authority
approves (or rejects) the
request for Identity
Proofing and upon
approval sends
information to Certificate
Authority
Relevant Provider
Entity /NonProvider
Delegatee
identification
information
Response to
Interoperability
Provider Entity or and System
Non-Provider
Delegatee request
for a Digital Identity
and request to
Certificate Authority
to issue Digital
Certificate/
Credentials
3
Certificate
Authority
Creates, Issues
and manages
security
credentials and
revocation lists
Certificate Authority
generates the Digital
Certificate/Credentials
and informs the Provider
Entity or Non-Provider
Delegatee of their
availability
Registration
Authority’s
approved Provider
Entity / NonProvider
Delegatee
identification
information
Digital Certificate/ Interoperability
Credentials made and System
available by
Certificate Authority
4A Provider Entity Receives Digital Provider Entity obtains
Certificate /
and incorporates Digital
Credentials
Certificate/ Credentials
into its business process
Digital Certificate / END
Credentials /
issued by
Certificate
Authority
Interoperability
or System Step
Interoperability
and System
Page 18
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
Table 4-1. Base Flow
Step Actor
4B Non-Provider
Delegatee
5
Role
Event/Description
Receives Digital Non-Provider Delegatee
Certificate /
obtains and incorporates
Credentials
Digital Certificate/
Credentials into its
business process
Provider Entity Delegation of
Rights Creator
Provider Entity creates
and signs Delegation of
Rights Assertion
Inputs
Outputs
Interoperability
or System Step
Digital Credentials END
/ Certificate issued
by Certificate
Authority
Interoperability
and System
Provider Entity
Delegation of
and Delegatee
Rights Assertion
Digital Certificate available
Information and
need to delegate a
right
Interoperability
and System
6A Provider Entity Attests to action Provider Entity completes Document and
on Document action on a Document and completed action
applies a non-repudiation
digital signature attesting
to the action
Digitally Signed
Document and
Signature Artifact
System
6B Delegatee
Digitally Signed
Document and
Signature Artifact
and request for
validated
Delegation of
Rights Assertion
Interoperability
and System
Attests to action Delegatee completes
Document and
on Document action on a Document and completed action
applies a non-repudiation
digital signature attesting
to the action and requests
validated Delegation of
Rights Assertion
6C Provider Entity Delegation of
Provider Entity system
Rights Validator validates and signs
Delegation of Rights
Assertion
6D Delegatee
Delegatee request Validated
for a validated
Delegation of
Delegation of
Rights Assertion
Rights Assertion
Applying
Delegatee associates the Validated
Delegation of
validated Delegation of
Delegation of
Rights Assertion Rights Assertion with the Rights Assertion
signed document
7A Provider Entity Document
Sender
Provider Entity sends
signed Document and
Signature Artifacts to
Payer Entity
Interoperability
and System
Digitally Signed
Document
Signature Artifact
and the validated
Delegation of
Rights Assertion
Interoperability
and System
Digitally Signed
Digitally Signed
Document and
Document and
Signature Artifact Signature Artifact
and need to send
to payer entity
Interoperability
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 19
July 2013
© 2013 Health Level Seven International. All rights reserved.
Table 4-1. Base Flow
Step Actor
Role
Event/Description
Inputs
Outputs
Interoperability
or System Step
7B Delegatee
Document
Sender
Delegatee sends signed
Document , Signature
Artifacts, and validated
Delegation of Rights
Assertion to Payer Entity
Digitally Signed
Document,
Signature Artifacts
and validated
Delegation of
Rights Assertion
and need to send
to payer entity
Digitally Signed
Document,
Signature Artifacts
and validated
Delegation of
Rights Artifacts
Interoperability
8
Receiver and
validator of
Document
Payer Entity receives
Document , authenticates
Signature Artifacts, where
appropriate any
Delegation of Rights
Assertions, and validates
data integrity of
submission from the
Provider Entity or
Delegatee
Digitally Signed
Document and
Signature Artifact,
and where
appropriate
Delegation of
Rights Assertion
Success or failure System
of Signature Artifact
validation,
Delegation of
Rights Artifacts
validation, and Data
integrity
authentication
Payer Entity
4.4
Functional Requirements
Functional Requirements identify the capabilities a system playing a role must have in order to enable
interoperable exchange of the healthcare data of interest. They provide a detailed breakdown of the
requirements in terms of the intended functional behaviors of the application. The Functional Requirements
include Information Interchange Requirements and System Requirements.
4.4.1
INFORMATION INTERCHANGE REQUIREMENTS
The Information Interchange Requirements define the system’s name and role. They also specify the actions
associated with the actual transport of content from the sending system to the receiving system.
Table 4-2. Information Interchange Requirements
Initiating System
Action
Information Interchange
Requirement Name
Action
Receiving System
Provider Entity Information
System
Send
Request for Digital Identity
Receive
Registration Authority Information
System
Non-Provider Delegatee
Information System
Send
Request for Digital Identity
Receive
Registration Authority Information
System
Registration Authority
Information System
Send
Digital Identity request
response and request to
issue Digital
Certificate/Credentials by
Certificate Authority
Receive
Certificate Authority Information
System
Certificate Authority Information
System
Send
Availability of Digital
Certificate/Credentials
Receive
Provider Entity Information System
Page 20
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
Table 4-2. Information Interchange Requirements
Initiating System
Action
Information Interchange
Requirement Name
Action
Receiving System
Certificate Authority Information
System
Send
Availability of Digital
Certificate/Credentials
Receive
Non-Provider Delegatee Entity
Information System
Provider Entity Information
System
Send
Link for Delegation of Rights
Assertion
Receive
Delegatee Information System
Delegatee Information System
Send
Request for validated
Delegation of Rights
Assertion
Receive
Provider Entity Information System
Provider Entity Information
System
Send
Validated Delegation of
Rights Assertion
Receive
Delegatee Information System
Provider Entity Information
System
Send
Document and Signature
Artifact
Receive
Payer Entity Information System
Delegatee Information System
Send
Document, Signature Artifact,
validated Delegation of
Rights Assertion
Receive
Payer Entity Information System
4.4.2
SYSTEM REQUIREMENTS
This section lists the requirements internal to the system necessary to participate successfully in the
transaction. System requirements may also detail a required workflow that is essential to the Use Case.
Table 4-3. System Requirements
System
System Requirement
Payer Entity Information System
a) Verify Delegation of Rights (if any), digital signatures, traceability to registered
provider, and validates integrity of Document
Provider Entity Information System
Incorporate signing Digital Certificate
Create Delegation of Rights if required
Respond to request to Validate Delegation of Rights Assertion
Performs actions on a Document (create, modify, read)
Apply non-repudiation Digital Signature to Delegation of Rights Assertion, and
Documents and creates Signature Artifacts
Delegatee Information System (usually
the same as Provider Entity Information
System
Incorporate signing Digital Certificate
Request Validated Delegation of Rights
Performs actions on a Document (create, modify, read)
Apply non-repudiation Digital Signature to Documents, creates Signature Artifacts
and attaches validated Delegation of Rights Assertion
Registration Authority Information System Process Provider and Non-Provider Delegatee identification information
Validate identification information for approval/rejection
Certificate Authority Information System
Generate Digital Certificate/Credentials
Manage Digital Certificate/Credential life cycle
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 21
July 2013
© 2013 Health Level Seven International. All rights reserved.
4.5
Sequence Diagram
A Sequence Diagram is primarily used to show the interactions between objects in the sequential order that
they occur. This representation can make it easy to communicate how the exchange works by displaying
how the different components interact. The primary use of the diagram is in the transition from
requirements expressed as use cases to the next and more formal level of refinement.
Payer Entity Information
System
Provider Entity Information
System
Delegatee
Information System
Certificate Authority
Information System
Registration Authority
Information System
1A. Provider Entity Sends request for Digital Identity to Registration Authority
1B. Non-Provider Delegatee Sends request for
Digital Identity to Registration Authority
Registration Authority
Sends request
to Certificate Authority
3A. Certificate Authority Informs
Provider Entity of Digital Certificate/
Credentials availability 3B. Certificate
2. Registration Authority
Approves or rejects
request for Identity Proofing
Certificate Authority Generates
Digital Certificate /Credentials
Authority Informs of
Non-Provider
Delegatee of Digital
Certificate/
Credentials availability
4A. Provider Entity obtains
and incorporates
Digital Certificate/Credentials
into business process
4B. Non-Provider Delegatee
obtains and incorporates
Digital Certificate/Credentials
into business process
5. Provider Entity creates
Delegation of Rights
Assertion
Optionally: Provider Entity
Sends link to Delegation
Of Rights Assertion to
Delegatee
6A. Provider Entity completes
Action on a Document and
Digitally signs Document
6B. Delegatee requests
validated Delegation of
Rights Assertion from
Provider Entity
6B. Delegatee completes
Action on a Document and
Digitally signs Document
6C. Provider Entity system
Validates and signs
Delegation of Rights Assertion
6C. Provider Entity system
Sends validated Delegation
of Rights Assertion
To Delgatee
7A. Provider Entity sends
Signed Document to
Payer Entity
6D. Delegatee attaches
Validated Delegation of
Rights Assertion to
Document
7B. Delegatee sends signed
Document To Payer Entity
8. Payer Entity Receives signed
Document, authenticates Digital
Certificates, Signature Artifact,
Delegation of Rights
Assertion and data integrity
FIGURE 2: BASE FLOW SEQUENCE DIAGRAM
Page 22
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
5 VERIFICATION OF X.509V3 PUBLIC DIGITAL CERTIFICATE
When an actor receives the X.509v3 public digital certificate of another actor, they must verify that:
1. The certificate is current
2. The certificate has been issued for an acceptable purpose
3. The trust anchor is acceptable by verifying the complete chain to a CA root certificate (or Federal
common policy CSP if in the US)
4. The altName field includes the required NPI or Alternative ID identification
5. The certificate has not been revoked by reviewing available OCSP response included in a digital
signature or querying an appropriate OCSP server or CRL list
If any of these steps fail, the certificate is not acceptable.
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 23
July 2013
© 2013 Health Level Seven International. All rights reserved.
6 DIGITAL SIGNATURE PROCESS
The Digital Signature process enables an individual or organization to digitally sign a CDA document.
The following actors may take part in the Digital Signature Process:


6.1
A Signer is the individual or organization that signs the CDA document.
A Signature Verifier is the individual or organization that receives the CDA document and must verify
the signature.
Pre-Conditions
1. Signer has obtained an X.509v3 digital certificate in compliance with the industry-accepted
requirements
2. Signer supports the required standards for the Digital Signature.
6.2
Signature Process
The Signer completes the following steps to digitally sign a CDA document:
1. Collects relevant artifacts into a single file
2. Generates digest of the entire document except for the following:
a. Inserted XAdES-X-L and SAML sections within the CDA header
b. legalAuthenticator and authenticator elements within the CDA header.
3. Signs digest using private key and generates signature
4. Includes signature and associated X.509v3 public digital certificate in all transactions in which CDA
document is exchanged
6.3
Verification Process for Signature
Upon receipt of a document bundle, signature, and X.509v3 public digital certificate, the Signature Verifier
completes the following steps to verify the Signature5:
1.
2.
3.
4.
5.
6.
5
Verify the X.509v3 Digital Certificate(s) (see Section 5)
Verifies that the signature date is appropriate
Verifies that the signature purpose is appropriate
Decrypts the signed digest with the public key from the X.509v3 public digital certificate
Computes the digest of the CDA document
Verifies that the signed digest matches the computed digest
Verification of the signature of a Delegation of Rights Artifact is identical (see Section 8).
Page 24
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
7 DIGITAL SIGNATURE STANDARD
XAdES-X-L is the standard to be used to sign a bundle of documents. It is an extension to the XML Digital
Signature (XML-DSIG) standard that adds support for long term signature verification via timestamps,
certificates, revocation lists, and additional features.
7.1
Issuing an XAdES-based Signature
Signatures must conform to the XAdES and CDA profiles with the following constraints:
1. One or more document artifacts must be collected into a single CDA file and the digital signature
must be applied to that CDA file
2. A signature must be applied directly to a Delegation of Rights Artifact6
3. Documents requiring long term signature validation should conform to the XAdES-X-L digital
signature form
4. XAdES-X-L digital signatures shall include an OCSP response
5. The Digital Signature Purpose code should be set to 1.2.840.10065.1.12.1.16 Administrative
7.2
Processing an XAdES-based based Signature
If a Signature Verifier receives a 2 Signature, they should complete the following steps to verify the identity
of the Signer and the integrity of the CDA document.
1. Verify the X.509v3 Certificate contained in the X509Certificate element (see Section 5)
2. Verify the signature contained in the Signature element (see Section 6.3)
If any of these steps fails, the Signature cannot be verified and the Signature Verifier should return an error
to the Signer.
6
This is included to support the signing of a Delegation of Rights Artifact.
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 25
July 2013
© 2013 Health Level Seven International. All rights reserved.
8 DELEGATION OF RIGHTS PROCESS
The Delegation of Rights process enables an individual or organization to assign a right to another party to
act on their behalf. The process presented here is meant to be broadly applicable to any situation in which a
right must be delegated to another party electronically. In order to clearly exhibit the use of a Delegation of
Rights Artifact back to the Digital Signature Process detailed in Section 5 of this guide, the examples below
focus on the signing of a CDA document.7
The following actors may take part in the Delegation of Rights Process:




A Delegator is the individual or organization that assigns the right.
A Delegatee is the individual or organization that receives the right.
A Delegation Agent is a third party trusted by the Delegator to confirm that an existing delegation of
rights is still valid.
A Delegation Verifier receives a delegation of rights artifact from a Delegatee and validates the
delegation.
In the context of this implementation guidance, these actors might be:




Delegator – Provider responsible for medical documentation
Delegatee – HIH registering the provider to receive eMDRs8 or providing medical documentation in
response to an eMDR, the same actor as the Signer (see Section 6)
Delegation Agent – EHR system of hospital where Provider works
Delegation Verifier – Payer that generated eMDR, the same actor as the Signature Verifier (see
Section 6)
Additionally, the following terms shall apply:



8.1
A Delegation of Rights Assertion is an assertion created by the Delegator prior to being signed
A Delegation of Rights Artifact is an assertion created and digitally signed by the Delegator
A Delegation Agent Signature is the digital signature of the Delegation Agent applied to a
Delegation of Rights Artifact
Overview of the Delegation of Rights Process
In general, the Delegation of Rights process proceeds as follows:
1. The Delegator issues a Delegation of Rights Artifact to the Delegatee (Section 8.3)
2. The Delegatee/Signer signs a bundle of documents on behalf of the Delegator (Section 6.2)
3. The Delegatee delivers the signed CDA document and Delegation of Rights Artifact to a Delegation
Verifier/Signature Verifier
4. The Delegation Verifier verifies the Delegation of Rights Artifact (Section 8.4)
5. The Delegation Verifier/ Signature Verifier verifies the Signature for the CDA document (Section 6.3)
7
The appropriate object must be signed by the Delegatee as their signature proves that they are the subject of the Delegation of Rights Assertion.
8
See “esMD Provider Profiles Authentication: Registration Implementation Guide” for additional guidance on this use case.
Page 26
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
However, a Delegation Verifier may require that a Delegation of Rights Artifact is first validated by a
Delegation Agent. In this case, the Delegation of Rights process proceeds as follows:
1. The Delegator issues a Delegation of Rights Artifact to the Delegatee (Section 8.3)
2. The Delegation Agent issues a Delegation Agent Signature to validate the Delegation of Rights
Artifact (Section 8.5)
3. The Delegatee/AoR Signer signs a CDA document on behalf of the Delegator (Section 6.2)
4. The Delegatee delivers the signed CDA document, the Delegation of Rights Artifact, and the
Delegation Agent Signature to a Delegation Verifier
5. The Delegation Verifier verifies the Delegation Agent Signature (Section 8.6)
6. The Delegation Verifier verifies the Delegation of Rights Artifact (Section 8.4)
7. The Delegation Verifier/ Signature Verifier verifies the Signature for the CDA document (Section 6.3)
See Diagram 1 for an overview of the Delegation of Rights Process.
DIAGRAM 1: OVERVIEW OF DELEGATION OF RIGHTS PROCESS
8.2



Pre-Conditions
Delegator, Delegatee, and Delegation Agent have obtained X.509v3 digital certificates in compliance
with industry-accepted requirements.
Delegator, Delegatee, and Delegation Agent support the required standards for the delegation of
rights.
Delegatee is aware of Delegation Verifier’s policy in regards to a Delegation Agent Signature.
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 27
July 2013
© 2013 Health Level Seven International. All rights reserved.
8.3
Process to Issue Delegation of Rights Artifact
The following steps must be taken for a Delegator to issue a Delegation of Rights Artifact to a Delegatee:
1. Delegatee must provide Issuer ID and Serial Number of their X.509v3 public digital certificate to the
Delegator
2. Delegator must generate a Delegation of Rights Assertion that includes the Issuer ID and Serial
Number provided by Delegatee as well as appropriate roles and limitations
3. Delegator must digitally sign the Delegation of Rights Assertion to create a Delegation of Rights
Artifact
4. Delegator must provide Delegation of Rights Artifact to Delegatee
5. Delegatee must include the Delegation of Rights Artifact in the relevant transaction with the
Delegation Verifier
8.4
Verification of Delegation of Rights Artifact
The Delegation Verifier completes the following steps to verify the Delegation of Rights Artifact.
1. Confirms all limitations within the Delegation of Rights Assertion are met, including subject of
assertion, dates of use, and purpose of use
2. Verifies the signature of the Delegation of Rights Artifact (see Section 6.3)
8.5
Process to Issue Delegation Agent Signature
Once a Delegator provides a Delegation of Rights Artifact to a Delegatee, there is no method to revoke that
right prior to its expiration date. This presents a security risk whereby assertions can be hijacked by a
malicious user. To insure that a Delegation of Rights Artifact is valid at the time of signature, a Delegation
Verifier may require that a Delegation Agent validate and sign the Delegation of Rights Artifact immediately
prior to its use by the Delegatee. The policies of the Delegation Verifier should define if this process is
required and the time frame in which it must take place.
A Delegatee must take the following steps immediately prior to using a Delegation of Rights Artifact in order
to prove to the Delegation Verifier that an existing Delegation of Rights Artifact remains valid:
1. Delegatee provides Delegation of Rights Artifact to Delegation Agent
2. Delegation Agent confirms all limitations within the Delegation of Rights Assertion are met,
including subject of assertion, dates of use, and purpose of use
3. Delegation Agent verifies the signature of the Delegation of Rights Artifact (see Section 6.3)
4. Delegation Agent confirms trust relationship exists with Delegator
5. Delegation Agent signs Delegation of Rights Artifact to create a Delegation Agent Signature
6. Delegation Agent returns the Delegation Agent Signature to the Delegatee
7. Delegatee includes the Delegation Agent Signature in the relevant transaction with the Delegation
Verifier
8.6
Verification of Delegation Agent Signature
This process is only necessary if the Delegation Verifier requires a Delegation Agent Signature. Upon receipt
of a Delegation of Rights Artifact and Delegation Agent Signature, the Delegation Verifier completes the
following steps to verify the validity of the Delegation of Rights Artifact.
Page 28
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
1. Verifies the Delegation Agent Signature (see Section 6.3)
2. Verifies signature timestamp falls within appropriate time frame as defined by Delegation Verifier
policies
8.7
Delegation of Rights Chaining
Situations may arise in which one party delegates a right to a second party, the second party proceeds to
delegate that right to a third party, and so on. The Delegation of Rights process supports such delegation of
rights chaining. To do so, each party must generate a Delegation of Rights Artifact (Section 8.3). The
Delegation Verifier must be provided with the entire chain of Delegation of Rights Artifacts. If the Delegation
Verifier requires a Delegation Agent Signature, then each Delegation of Rights Artifact in the chain must
have a corresponding Delegation Agent Signature (Section 8.5).
The Delegation Verifier should verify each Delegation of Rights Artifact (Section 8.4) in a recursive fashion,
by confirming that the Delegator of the most recent Delegation of Rights Artifact is the Delegatee of the
prior Delegation of Rights Artifact. This should continue until the original Delegation of Rights Artifact has
been verified and is confirmed to have been issued by the appropriate party.
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 29
July 2013
© 2013 Health Level Seven International. All rights reserved.
9 DELEGATION OF RIGHTS STANDARD
This guide establishes use of the OASIS Security Assertion Markup Language (SAML) standard to support
Delegation of Rights. OASIS SAML specifies a data format for exchanging authentication and authorization
data between parties.
SAML specifies the use of the XML Digital Signature (XML-DSIG) standard to sign SAML assertions.
For delegation of rights requiring long term validation, this guide establishes use of the XML Advanced
Electronic Signatures (XAdES) standard. XAdES is an extension to XML-DSIG that adds support for long term
signature verification via timestamps, certificates, revocation lists, and additional features.
This guide establishes use of the XADES-X-L standard to support the Delegation Agent Signature.
Name of Specification
Purpose
OASIS SAML
Delegation of Rights Assertion
XAdES-X-L
Sign assertion to create Delegation of Rights Artifact
XAdES-X-L
Long term signature support
XAdES-X-L
Sign Delegation of Rights Artifact to create Delegation Agent Signature
The Delegation of Rights Artifact is meant to prove that a Delegatee is authorized to sign a CDA document
on behalf of the individual or organization responsible for that document.
The Delegator (e.g. Provider, Provider Organization, or a trusted third party delegated to act on their behalf)
shall create and deliver a signed SAML assertion to the Delegatee. The Delegatee shall act as the Signer and
digitally sign a CDA document.
OASIS defines a number of specifications to support the exchange of SAML assertions; however, delivery of
the SAML assertions between actors is outside the scope of this implementation guide.
9.1
Issuing a SAML based Delegation of Rights Artifact
The Delegation of Rights Artifact shall contain a signed SAML assertion compliant with “saml-core-2.0-os:
Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0.” The following
constraints apply to a Delegation of Rights Artifact:
The Subject of the assertion must be included and must be the Delegatee
The SubjectConfirmation method must be holder-of-key
The SubjectConfirmationData element must include a KeyInfo element
The SubjectConfirmationData KeyInfo type must be X509Data
The SubjectConfirmationData KeyInfo element must contain the X509IssuerSerial
of the X.509v3 certificate that holds the public key that will be used to verify the Signature on the
document bundle (i.e. the public certificate of the Delegatee/Signer)
6. The SAML assertion must be signed by the Delegator
7. The Signature element must include a KeyInfo element
8. The Signature KeyInfo type must be rawX509Certificate
1.
2.
3.
4.
5.
Page 30
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
9. The Signature KeyInfo element must contain the X.509v3 certificate that holds the public key
that will be used to verify the signature of the SAML assertion (i.e. the public certificate of the
Delegator)
This guide makes the following recommendations to limit the use of the delegation of rights artifact:


Assertion should use NotBefore and NotOnOrAfter elements within the
SubjectConfirmationData element to bound use of the assertion to a reasonable time frame
Assertion should define an Attribute of the Subject that describes their business relationship.
This guide makes the following recommendations when signing the SAML Assertion:


9.1.1
Delegation of Rights Artifacts associated with documents requiring long term signature validation
should conform to the XAdES-X-L digital signature form
XAdES-X-L digital signatures shall include an OCSP response
PROCESSING A SAML BASED DELEGATION OF RIGHTS ARTIFACT
If a Delegation Verifier/Signature Verifier (e.g. Payer/Payer Contractor) receives a document bundle and an
associated Delegation of Rights Artifact, they should complete the following steps to verify that the
Delegatee/Signer has the right to sign the CDA document on behalf of the Delegator.
1. Confirm that any limitations defined within the Delegation of Rights Assertion are met, including:
a. Current date falls within NotBefore and NotOnOrAfter elements
b. Attribute of the Subject describes a business relationship appropriate for signing a
CDA document
2. Use the X.509v3 certificate referenced in the Signature KeyInfo element to validate the
identity of the entity that signed the assertion (i.e. the Delegator)
3. Confirm trust in the entity that signed the assertion (i.e. the Delegator)
4. Verify the signature contained in the Signature element of the assertion (see Section 6.3)
5. Confirm that the SubjectConfirmationData KeyInfo element references the same
X.509v3 certificate that holds the public key that will be used to verify the Signature on the CDA
document (i.e. the certificate of the Delegatee/Signer)
If any of these steps fails, Delegation of Rights cannot be confirmed and the Verifier should return an error
to the Delegatee. If these steps are successful, delegation of rights has been confirmed and the Verifier
should verify the signature of the CDA document as defined in Section 6.3.
9.2
Issuing a Delegation Agent Signature
A Delegation Verifier may require that a Delegation Agent validate and sign the Delegation of Rights Artifact
immediately prior to its use. In this case, a Delegatee and Delegation Agent must take the following steps
immediately prior to using a Delegation of Rights Artifact:
1. Delegatee provides Delegation of Rights Artifact to Delegation Agent
2. Delegation Agent confirms that any limitations defined within the Delegation of Rights Assertion are
met, including:
a. Current date falls within NotBefore and NotOnOrAfter elements
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 31
July 2013
© 2013 Health Level Seven International. All rights reserved.
3.
4.
5.
6.
b. Attribute of the Subject describes a business relationship appropriate for signing a
document bundle
Delegation Agent verifies the Delegator signature in the Delegation of Rights Artifact (see Section
6.3)
Delegation Agent confirms they have a trust relationship with Delegator
Delegation Agent creates a Delegation Agent Signature by applying an XAdES-based Signature as
defined in Section 7.1 to the Delegation of Rights Artifact
Delegation Agent returns the Delegation Agent Signature to the Delegatee
This guide makes the following recommendations:



9.2.1
Delegation Agent Signatures associated with documents requiring long term signature validation
should conform to the XAdES-X-L digital signature form
XAdES-X-L digital signatures should include an OCSP response
The mandatory XAdES SigningTime element specifies the time at which the Delegation Agent
performed the signing process and should fall within an appropriate time frame as defined by the
policies of the Delegation Verifier
PROCESSING ADELEGATION AGENT SIGNATURE
If a Delegation requires and receives a Delegation Agent Signature, they should complete the following steps
to verify the validity of the Delegation of Rights Artifact:
1. Verify the Delegation Agent Signature as defined in Section 6.3: Verification Process for Signature
2. Verify that the SigningTime element falls within appropriate time frame as defined by
Delegation Verifier policies
If any of these steps fail, the Delegation Agent Signature cannot be verified and the Verifier should return an
error to the Delegatee. If these steps are successful, the validity of the Delegation of Rights Artifact has been
confirmed and the Verifier should proceed to verify the SAML based Delegation of Rights Artifact as defined
in Section 9.1.1.
Page 32
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013
10 INCORPORATING ARTIFACTS INTO A CDA DOCUMENT
[Incorporate info on signers/authors being in the document 2x; authenticators and legal authenticators will
be the “Digital signers” – coordinate with Bob Dolin/LCC IG team for consistency; what is scope of digest (all
except authenticator/legal authenticator), clarity on topic of multiple signatures on document]
This guide identifies use of the signatureText element within the HL7 RIM. signatureText
provides a “textual or multimedia depiction of the signature by which the participant endorses his or her
participation…and that he or she agrees to assume the associated accountability.” signatureText
represents digital signature by reference to a signature data block (i.e., the XAdES-X-L elements) within the
CDA header.
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
Page 33
July 2013
© 2013 Health Level Seven International. All rights reserved.
11 APPENDIX A: EXAMPLE
The following XML examples present an XAdES-X-L Signature, a SAML based Delegation of Rights Artifact,
and an XAdES-X-L Signature for that Delegation of Rights Artifact.
11.1 XAdES-X-L Digital Signature
<To Be Developed>
11.2 SAML Delegation of Rights Artifact
<To Be Developed>
11.3 XAdES-X-L Digital Signature Applied to SAML Delegation of Rights
<To Be Developed>
Page 34
HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1
© 2013 Health Level Seven International. All rights reserved.
July 2013