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).

Click on the “chat” bubble at the top of the meeting window to

send a chat.

Agenda

Topic Time Allotted

Announcements 5 minutes

HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1Presentation 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 Questions 5 minutes

4

Oct. Nov. Dec. Jan. Feb. March April MayToday

Stan

dard

s Ev

alua

tion

Solu

tion

Plan

ning

IG D

evel

opm

ent

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 & Assessment1/8-2/5

Data Provenance Standards Presentations ScheduleDate Standard to Present SME Name Confirmed

11/20/2014 ISO 21089 Health Informatics: Trusted End-to-End Information Flows Gary Dickinson YSOAP Glen Marshall Y

THANKSGIVING HOLIDAY

12/4/2014

1. C-CDA2. CDA R23. HL7 Implementation Guide for CDA® Release 2: DataProvenance, Release 1 – US Realm4. 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

YHL7 EHR Records Management and Evidentiary Support (RM-ES) Functional Model, Release 1

Reed GelzerDiana 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 vocabularyHL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1

Kathleen Connor

YHL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1 Kathleen Connor +

Serafina Versaggi Y

1/15/2015HL7 FHIR DSTU Release 1.1 Provenance Resource Reed Gelzer +

Gary Dickinson N

Updated Candidate Standards

# Transaction Content and Structure Terminology and Code Values - DP Transport Security

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

Digital Signatures and Delegation of Rights

Presentation to Data Provenance

December 18th, 2014

HL7 Implementation Guide for CDA® Release 2: Digital Signatures and Delegation of Rights, Release 1

HL7 DSTU Sponsored by:

Structured Documentation Work GroupAttachments Work GroupSecurity Work Group

HL7 CDA Digital Signatures

• 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

• 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

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

• 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

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

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

• 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

• 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:– <thumbnail mediaType="text/plain" representation="TXT">– 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

CDA HeaderShows 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.

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

SignatureTextThe 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.

SignerRoleWithin 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.

SignaturePurposeWithin 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.

Questions?

HL7 Records Management and Evidentiary Support Profile (RMES)

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)

Source ReliabilityProvenance 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.

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.

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.

Support Team and QuestionsPlease feel free to reach out to any member of the Data Provenance

Support Team:• Initiative Coordinator: Johnathan Coleman: jc@securityrs.com • OCPO Sponsor: Julie Chua: julie.chua@hhs.gov • OST Sponsor: Mera Choi: mera.choi@hhs.gov• Subject Matter Experts: Kathleen Conner: klc@securityrs.com and Bob Yencha:

bobyencha@maine.rr.com • Support Team:

– Project Management: Jamie Parker: jamie.parker@esacinc.com – Use Case Development: Atanu Sen: atanu.sen@accenture.com– Harmonization and Standards Development Support:

» Alex Lowitt: alexander.s.lowitt@accenturefederal.com» Atanu Sen: atanu.sen@accenture.com» Perri Smith: perri.smith@accenturefederal.com

– Support: Lynette Elliott: lynette.elliott@esacinc.com and Apurva Dharia: apurva.dharia@esacinc.com