Electronic Submission of Medical Documentation (esMD) AoR L2 Harmonization April 17, 2013

Meeting Etiquette Please announce your name each time prior to making comments or suggestions during the call Remember: If you are not speaking keep your phone on mute Do not put your phone on hold – if you need to take a call, hang up and dial in again when finished with your other call –Hold = Elevator Music = very frustrated speakers and participants This meeting, like all of our meetings, is being recorded –Another reason to keep your phone on mute when not speaking! Feel free to use the “Chat” or “Q&A” feature for questions or comments NOTE: This meeting is being recorded and will be posted on the esMD Wiki page after the meeting From S&I Framework to Participants: Hi everyone: remember to keep your phone on mute 2

Agenda 3 TopicPresenter Announcements and Administrative ItemsSweta Ladwa AoR L2 Harmonization Kick-off AoR L1 Summary Harmonization/Standards Overview Digital Signatures Sweta Ladwa Zachary May Bob Dieterle

Wednesday, PM ET: eDoC Workgroup meeting –1 - 2 PM ET: eDoC Use Case Meeting –2 - 3 PM ET: eDoC Structured Data SWG Meeting Friday, PM: eDoC Structured Data SWG Meeting Schedule

esMD Initiative Timeline Author of Record WG SDS 11/30-12/7 Charter Consensus Oct ‘11 Kick-Off/ F2F October‘13 April ‘12Oct ‘12 April ‘13 Jan ‘12July ‘12 Jan ‘13July ‘13 Use Case and Requirements L1 Pre-Discovery AoR Workgroup Through April 2014 AoR L1 SWGs Use Case and Requirements L2 Harmonization L2 Pilots (TBD) Implementati on Guide for AoR L1 Electronic Determination of Coverage eDoC Use Case and Requirements eDoC Harmonization Pilots (TBD) Today 4/17/13 PMD User Story PMD Harmonizat ion

AoR Level 1 Summary The AoR L1 IG identifies the following: A digital signature standard for a document bundle, including support for a signed digest of the message, signer’s public certificate, purpose of signature, timestamps, and long-term validation data. A delegation of rights standard that supports certificate ID from both parties, purpose of the delegation, and effective date range of the assertion. A method to validate an existing delegation of rights artifact It supports the following use cases: A document owner applies a digital signature to a document bundle The owner delegates the right to another party to apply a digital signature on the owner’s behalf.

AoR Level 1 Summary – Key Components

AoR Level 1 Summary – Selected Standards Digital Signatures: IHE DSG content profile Delegation of Rights: OASIS SAML. SAML specifies the XML-DSIG standard for signing SAML assertions. XML-DSIG has an extension–XAdES—which supports long-term validation. IHE DSG is used to support AoR L1 Delegation Agent signatures.

AoR -- Phased Scope of Work 9 Level 1 – Completed Level 2 – Current Focus Level 3 - TBD Digital signature on aggregated documents (bundle) Digital signature to allow traceability of individual contributions to a document Digital signature on an individual document Focus is on signing a bundle of documents prior to transmission to satisfy an eMDR Define requirements for esMD UC 1 and UC 2 Signature Artifacts May assist with EHR Certification criteria in the future Focus is on signing an individual document prior to sending or at the point of creation by providers Will inform EHR Certification criteria for signatures on patient documentation Focus is on signing documents and individual contributions at the point of creation by providers Will inform EHR Certification criteria for one or multiple signatures on patient documentation

The S&I Framework Standards Evaluation Process Goal of the S&I Framework Standards Evaluation Process: To achieve consensus on applicable and relevant standards to be modified or further developed as a resolution to the health information exchange challenge addressed by the Initiative. The process narrows the initial Candidate Standards List toward Selected Standards to be included in the Initiative’s Recommended Standards consensus statement

The S&I Framework Standards Evaluation Process 1.Discuss esMD-specific harmonization issues Code sets, vocabularies, and security, and signature standards will be discussed in future meetings 2.Evaluate and analyze standards Use Standards Analysis Workbook to capture findings and rate applicability of each standard to esMD 3.Select standards for further development within esMD initiative Choose standards based on use case and data model requirements and community expertise 4.Draft Standards Recommendation Consensus Statement

esMD AoR Harmonization Challenges 1.AoR L2 Signature Requirements Internal Signatures to the Document vs. External Signatures to the Document 2.EHR System compatibility for Internal Document Signatures 3.Signature capabilities for other transaction types (e.g. – HL7 v2.x, imaging, pharmaceuticals, orders, etc.) 1.Different MIME type or text blob?

IHE DSG – Strengths and Weaknesses Strengths -Supports transmission of signatures and certificates -Based on XAdES which provides long-term validation of signatures -Reusable and can be used to sign any kind of document -XML transforms are not required -Signatures applied to payload and processed by internal system -Supports counter signatures and co-signatures -Works for XDS, XDM, XDR, XCA (but may be used elsewhere) Weaknesses -Receiver must track both signed document and signature document -Applicability limited to signing of documents -Probably does not meet AoR Level 3 requirements -Applies to the whole document but does not support partial signatures / signing part of a document

CDA – Strengths and Weaknesses Strengths -Covers all MIME types -Supports tracking of changes -XML digital signatures can be embedded within the document itself and allows XML encoding transformation -Supports consent being digitally signed with DSG -Supports encapsulation of a scanned document (e.g., a wet signature) using the XDS-SD profile -Allows patient demographics to change in PID -Signature is embedded and cannot be lost, but can be stripped Weaknesses -Applies to the whole document but does not yet support partial signatures / signing part of a document -Support for Assertions is unclear -Support for multiple signatures and/or multiple certificates is unclear -Type of digital signature embedded within the document is unclear -Native header structure does not support delegation of rights

PDF – Strengths and Weaknesses Strengths -Supports multiple signatures and incremental updates -Supports limitation on post-signing changes -Supports legal content attestations -Supports timestamp information and revocation checking details for both CRLs and OCSP -Signatures are auditable -EchoSign also supports Microsoft Office, JPEG, HTML Weaknesses -Issues with tracking changes, maintaining the data structure, and long-term validation -Supports multiple signers, but may not support multiple embedded certificates -Constrained to PDF architecture/authentication -Lacks support for partial signatures -Does not support delegation of rights -Limited to Adobe (software specific) -Signing Certificate access issues

AoR L2 Digital Signature Considerations CDA (Section)CDA (MSH) DSGPDF Signature Location InternalExternalInternal Date/timestamp Part of Signing Software Yes (Internal to PDF) Delegation of Rights YesNoYesNo Long-Term Validation TBDNoYes (via XMLSig/XAdES) Yes (via PAdES) Multiple Signatures TBD(2.0?)Yes Purpose No apparent support, but could be extrapolated from signature/role combination Yes – purpose list defined in ASTM E1762 Supports purpose statement, but possibly not a constrained purpose list