1. Data Provenance Community Meeting December 18, 2014

2. Meeting Etiquette Please mute your phone when you are not speaking to prevent background noise. – All meetings are recorded. Please do not put your phone on hold. – Hang up and dial back in to prevent hold music. Please announce your name before speaking Use the “Chat” feature to ask questions or share comments. – Send chats to “All Participants” so they can be addressed publicly in the chat, or discussed in the meeting (as appropriate). 2 Click on the “chat” bubble at the top of the meeting window to send a chat.

3. Agenda TopicTime Allotted Announcements5 minutes HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1 Presentation by Bob Dieterle 25 minutes HL7 EHR Records Management and Evidentiary Support (RM- ES) Functional Model, Release 1 Presentation by Reed Gelzer and Diana Warner 25 minutes Comments and Questions5 minutes

4. 4 Today Standards Evaluation Solution Planning IG Development DPROV Harm Launch Standards SME presentations Solution Planning Create IG Template Introduction Implementation Approach Suggested Enhancements End-to-End Review 1/29 – 3/5 10/23 – 1/8 12/15 - 1/5 1/22 - 2/5 3/5 – 4/5 4/5 – 4/12 4/12 – 5/5 DPROV Harmonization Timeline Standards Analysis & Assessment 1/8-2/5

5. Data Provenance Standards Presentations Schedule DateStandard to PresentSME NameConfirmed 11/20/2014 ISO 21089 Health Informatics: Trusted End-to-End Information FlowsGary Dickinson Y SOAPGlen Marshall Y THANKSGIVING HOLIDAY 12/4/2014 1. C-CDA 2. CDA R2 3. HL7 Implementation Guide for CDA® Release 2: Data Provenance, Release 1 – US Realm 4. HL7 V2 Bob Yencha + Kathleen Connor Y 12/11/2014 1.HL7 EHR Interoperability Model DSTU (2007) 2. HL7 Implementation Guide for CDA Release 2: Reference Profile for EHR Interoperability DSTU (2008) 3. HL7 EHR Lifecycle Model DSTU (2008) 4. ISO/HL7 10781 EHR System Functional Model, Release 2 (2014) 5. HL7 Record Lifecycle Events on FHIR (project underway 2014 for FHIR DSTU Release 2) Gary Dickinson Y 12/18/2014 HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1 Bob Dieterle Y HL7 EHR Records Management and Evidentiary Support (RM-ES) Functional Model, Release 1 Reed Gelzer Diana Warner Y 1/8/2015 As a grouping of Implementation Guides: 1. HL7 Health Care Privacy and Security Classification System, Release 1 2. HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) 3. HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS) *Associated vocabulary HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 Kathleen Connor Y HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1 Kathleen Connor + Serafina Versaggi Y 1/15/2015 HL7 FHIR DSTU Release 1.1 Provenance Resource Reed Gelzer + Gary Dickinson N

6. Updated Candidate Standards #TransactionContent and Structure Terminology and Code Values - DP TransportSecurity 1 a) Start Point sends clinical data with provenance information to End Point *C-CDA *CDA R2 *W3C PROV: PROV-AQ, PROV- CONSTRAINTS, PROV-XML *Personal Health Record System Functional Model *HL7 EHR Records Management and Evidentiary Support (RM-ES) Functional Model, Release 1 *ISO/HL7 EHR System Functional Model Release 2 *HL7 EHR Lifecycle Model (2008) *HL7 Record Lifecycle Event Metadata using FHIR (project underway 2014) *HL7 V.2.x *ISO 21089 Health Informatics: Trusted End-to-End Information Flows *HL7 FHIR DSTU Release 1.1 Provenance Resource *HL7 Implementation Guide for CDA® Release 2: Data Provenance, Release 1 – US Realm *HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1 *HL7 EHR Interoperability Model DSTU (2007) *HL7 Implementation Guide for CDA Release 2: Reference Profile for EHR Interoperability DSTU (2008) *HL7 V.2/ V.3 Vocabulary & Terminology Standards *Representation State Transfer (RESTful) *Cross Enterprise Document-Sharing XDS *SOAP *HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 * HL7 Health Care Privacy and Security Classification System, Release 1 (HCS) *HL7 Version 3 Standard: Privacy, Access and Security Services (PASS) *HL7 Version 3 Standard: Privacy, Access and Security Services; Security Labeling Service, Release 1 (SLS) *HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1 2 a) Start Point sends clinical data to transmitter with provenance information 2 b) Transmitter send clinical data to end point with provenance information 3 a) Start Point sends clinical data to assembler/composer with provenance information 3 b) Assembler/composer compiles clinical data which is sent to end point with provenance information

7. Digital Signatures and Delegation of Rights Presentation to Data Provenance December 18 th, 2014

8. HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1 HL7 DSTU Sponsored by: Structured Documentation Work Group Attachments Work Group Security Work Group HL7 CDA Digital Signatures

9. This implementation guide defines a method to imbed digital signatures in a CDA document and provides an optional method of specifying delegation of right assertions that may be included with the digital signatures. This implementation guide will allow health plans, payers, and providers to accurately authenticate the Authorized Signer(s) of a CDA document and trust the validity and authenticity of signed medical documentation. This implementation guide specifies the content of the sdtc:signatureText element when included as part of the legalAuthenticator and/or authenticator participant occurrences. Examples of the sdtc:signatureText are defined in the HL7 Implementation Guide for CDA® Release 2: Consolidated CDA Templates for Clinical Notes (US Realm) Draft Standard for Trial Use Release 2 (C-CDA) Background

10. This document provides guidance on the use of digital signatures imbedded in a CDA document to: Provide a non-repudiation signature that attests to the role and signature purpose (see Table 4 ‑ 4. Code Sets for role and signature purpose code sets) of each Authorized Signer to the document. Provide for a delegation of rights where the signer is a Delegated Signer and not the Authorized Signer responsible individual or organization (e.g., the signer is acting as an authorized agent). Provide a medical/legal attestation for administrative and clinical purposes such as documenting transfer of clinical care Provide for both digital co-signatures and counter signatures. Purpose

11. An Authorized Signer may play a role in the document, such as ‘author’, and would therefore be represented in the author participation declared in the header. The Authorized Signer will also be represented as an authenticator in the header. In the sdtc:signatureText for the authenticator, the Authorized Signer will have a signerRole. If this Authorized Signer claims to be an anesthesiologist, signing as an author, then this information would be represented in the signerRole as the claimedRole and signaturePurpose. Through appropriate use of both signerRole and signaturePurpose, digital signatures can accommodate co-signatures on any CDA (e.g. multiple Authorized Signers can indicate that they are co-authors). In addition, since the XAdES-X-L standard used by this guide supports counter signatures, any digital signature may be countersigned. Example

12. Identify a method of incorporating digital signatures and delegation of right assertions into the header of a CDA document. Identify a digital signature standard for a CDA document that supports the exchange of a signed: – Digest of the message; – Timestamp; – Role of the signer; – Purpose of signature. Identify a digital signature standard for: – The public certificate of the signer; – 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: – The certificate ID of both parties; – The purpose of the delegation; – The effective date range of the assertion. Identify a method to validate an existing delegation of rights assertion.. Goals of IG

13. The signer creates the XAdES-X-L Digital Signature and populates it with all required elements including: The signer’s public X.509v3 signing certificate The Digest of the CDA (see Section 3.1.2 and the SignedProperties) The Signed Digest The following signed elements: – Coordinated Universal Time (UTC) – Role Healthcare Taxonomy Data Set Personal and Legal Relationship Role Type – Signature Purpose ASTM E 1762-95 – A signed OCSP (Online Certificate Status Protocol) or CRL (Certificate Revocation List) in the RevocationValues element Signature Process

14. In general, the Delegation of Rights process proceeds as follows: The Authorized Signer creates and digitally signs a Delegation of Rights Assertion; the resulting Delegation of Rights Artifact is provided to the Delegated Signer. When creating a Digital Signature, the Delegated Signer requests a Validated Delegation of Rights Artifact from the Delegation Validator. Assuming the Delegation of Rights is still valid, the Delegation Validator issues a Validated Delegation of Rights Artifact. The Delegated Signer signs a CDA document on behalf of the Authorized Signer and includes the Validated Delegation of Rights Artifact as proof of the granted right to sign. Overview of Delegation of Rights

15. The following steps must be taken for an Authorized Signer to issue a Delegation of Rights Artifact to a Delegated Signer: Authorized Signer creates Delegation of Rights Assertion that includes the following: – Issuer/ID of Delegated Signer X.509v3 signing certificate, – Issuer/ID of Authorized Signer X.509v3 signing certificate, – Start and End date of assertion, – Right to sign is delegated; Authorized Signer signs the Delegation of Rights assertion using the XAdES-X-L standard syntax; The resultant signed Delegation of Rights Assertion is the Delegation of Rights Artifact. Creating a Delegation of Rights Artifact

16. The sdtc:signatureText element is an ED data type and permits the definition of a thumbnail to provide a human readable version of the Digital Signature: – – The thumbnail text string SHOULD contain the following elements for an Authorized Signer: “Digitally Signed by Authorized Signer” – The thumbnail text string SHOULD contain the following elements for a Delegated Signer: “Digitally signed by Delegated Signer ” – Signers name – Date and time of signature – Role – Purpose – Delegated right to sign by with Name of the right delegator Example Text (Authorized Signer): Digitally signed by Authorized Signer John Doe on 4/21/2013 at 15:30 EDT as Physician for the purpose of Author’s signature. Example Text (Delegated Signer): Digitally signed by Delegated Signer John Doe on 4/21/2013 at 15:30 EDT as Physician for the purpose of Co-author’s signature. Delegated right to sign by Jane Doe. SignatureText Specification

17. CDA Header Shows the CDA containing a header and a body, with the key header elements on the right including participation types, some of which are optional but are included for illustrative purposes.

18. Authenticator Shows the header elements, and on the right the authenticator element which contains four important top-level tags under it.

19. SignatureText The sdtc:signatureText tag contains the ds:Signature tag, which further contains the ds:Object tag. The ds:Object tag contains the XAdES elements. Further nested under the ds:Object tag is QualifyingProperties tag, which contains both SignedProperties and UnsignedProperties.

20. SignerRole Within SignedProperties, there is the SignedSignatureProperties tag, which contains the SignerRole tag. This tag indicates the role of the Authorized Signer. The SignerRole tag can either contain a ClaimedRoles or CertifiedRoles tag. The ClaimedRoles tag contains the ClaimedRole tag, which is used to specify the asserted role of the signer using the Healthcare Taxonomy Code Set. In this example, the code is set to Trauma Surgery (2086S0127X). Role can also be indicated using CertifiedRoles, however the CertifiedRole tag calls for a base64encrypted data type.

21. SignaturePurpose Within SignedSignatureProperties, we can also indicate the SignaturePurpose using the ASTM E-1762 code set – in this case, to provide more granularity and clarity as to the Signer’s role. In this example, the Signer indicates he/she is signing as a coauthor.

22. Questions?

23. HL7 Records Management and Evidentiary Support Profile (RMES)

24. Testimony HIT PC Feb 2013 Chad P. Brouillard, Esq. – Healthcare Attorney – Foster & Eldridge, LLP Michelle L. Dougherty, MA, RHIA, CHP – Director of Research & Development – AHIMA Foundation Donald T. Mon, PhD – Senior Director – Center for Advancement of Health Information Technology (CAHIT)

25. Source Reliability Provenance Metadata for Record Life Cycle Events Metadata Criticality: Provides assurance that the record was created and maintained in a legitimate manner as well as supporting information integrity. Realm-Specific Guidance: Ex: The American Bar Association has resources on metadata for establishing digital record provenance. Secondary Use Validation: In addition to support for information integrity, metadata also provides a mechanism for data analytics and forensics to occur. EHR systems have metadata and audit records, but there is not a standard baseline of minimal features found in all EHR applications. There are not consistent definitions or applications of metadata across all EHR applications making data analytics very difficult.

26. Validity’s Objective The medical record as a credible source supporting patient care and as evidence detailing care delivery and decision making. For information created and maintained in computer systems, additional attributes are important to ensure validity and trustworthiness of the information and records including processes for maintaining the system, procedures for entry and retrieval of information, assurances for the reliability and accuracy of the information, and validation that information has not been altered.

27. Recommendations Include on DPROV objectives (and task timelines) that Source Reliability required for Interoperability Simplify Source Reliability uptake by using RMES principles as built into EHR-FM R2 RI and TI sections Summary: Reconciling concepts and vocabularies of Source Reliability with Interoperability (esp. Access Controls) will invest DPROV with necessary requirements for achieving national policy objectives for HIT.

28. Support Team and Questions Please feel free to reach out to any member of the Data Provenance Support Team: Initiative Coordinator: Johnathan Coleman: jc@securityrs.comjc@securityrs.com OCPO Sponsor: Julie Chua: julie.chua@hhs.govjulie.chua@hhs.gov OST Sponsor: Mera Choi: mera.choi@hhs.govmera.choi@hhs.gov Subject Matter Experts: Kathleen Conner: klc@securityrs.com and Bob Yencha: bobyencha@maine.rr.comklc@securityrs.com bobyencha@maine.rr.com Support Team: – Project Management: Jamie Parker: jamie.parker@esacinc.comjamie.parker@esacinc.com – Use Case Development: Atanu Sen: atanu.sen@accenture.comatanu.sen@accenture.com – Harmonization and Standards Development Support: » Alex Lowitt: alexander.s.lowitt@accenturefederal.comalexander.s.lowitt@accenturefederal.com » Atanu Sen: atanu.sen@accenture.comatanu.sen@accenture.com » Perri Smith: perri.smith@accenturefederal.comperri.smith@accenturefederal.com – Support: Lynette Elliott: lynette.elliott@esacinc.com and Apurva Dharia: apurva.dharia@esacinc.comlynette.elliott@esacinc.com apurva.dharia@esacinc.com