1. Security Standards under Review for esMD

2. Transaction Timeline An esMD transaction begins with the creation of some type of electronic content (e.g. X12 274, 277, or 275 message or an HPD Plus DSML, CDA, or PDF document). As the content is packaged into a message and sent, security elements are added at points along the timeline dependent on the standard(s) selected and the purpose of the security element. This process is reversed on the receiving end. Electronic Content Created Content Stored as a document XD* Metadata Content packaged into payload Message created Message Sent DSG Signature X12 58 Signature WS- Security Encryption (transport level) CAQH CORE Metadata Internal SystemsGateway Message Received Process Header Process Payload X12 58 Signature WS- Security CAQH CORE/ XD* Metadata Process Content DSG Signature Internal Systems GatewayInternet Store Content

3. IHE DSG The Document Digital Signature (DSG) content profile specifies the use of XML Advanced Electronic Signatures (XAdES) for documents that are shared between organizations. Process Flow for Phase 1 Sending Medical Documentation Transaction Structure

4. Extensions to Metadata This approach would extend existing metadata to support the exchange of the required security information. For esMD, this would require extensions to CAQH CORE and XD* metadata. We would need to work with the relevant organizations to seek inclusion of these changes in future specifications. Process Flow for UC1 Registration Transaction Structure

5. X12 58 This standard defines the data formats for authentication, encryption, and assurances in order to provide integrity, confidentiality, and verification and non-repudiation of origin for two levels of exchange of EDI formatted data defined by ASC X12. Process Flow for UC1 Registration Transaction Structure

6. WS-Security This specification extends SOAP Messages to provide three main security capabilities: the ability to send security tokens as part of a message, message integrity, and message confidentiality. Process Flow for UC1 Registration Transaction Structure

7. esMD Security Requirements

8. Identity Requirements RequirementDescriptionRegistrationSend eMDR Send eMD Include Sender's public digital certificate in transaction - Receiver traces certificate to root CA in order to verify sender's identity. - Receiver uses public key and digital signature to verify authenticity. yyy Include additional public digital certificates in transaction - Transaction includes public digital certificates of all other parties of interest. - Receiver traces certificates to root CAs in order to verify identity of all other parties of interest. - Receiver uses public keys and digital signatures to verify authenticity of all other parties of interest. - Receiver uses certificates to verify all delegation of rights artifacts created by other parties of interest. yny

9. Authenticity Requirements RequirementDescriptionRegistrationSend eMDR Send eMD Include one digital signature in transaction - Sender signs message - Receiver uses digital signature to verify authenticity of message yyy Include additional digital signatures in transaction - Content creators sign all or portion of payload - Receiver uses digital signatures to verify authenticity of content yny Supports digital signature chains - Receiver understands the order in which digital signatures were applied - Receiver understand what part of the transaction each digital signature applies to yny Supports long term validation of digital signatures - Receiver can validate digital signature up to twenty years after signing - Content creator adds time-stamped and CA signed OCSP response or CRL to content at time of creation nny

10. Authority Requirements RequirementDescriptionRegistrationSend eMDR Send eMD Include single delegation of rights artifacts in transaction - Party A delegates a right to Party B who may not delegate that right to any other party nnn Include multiple delegation of rights artifacts in transaction - Party A delegates a right to Party B who may delegate that right to Party C yny Supports delegation of rights artifact chains - Receiver understands the order in which rights were delegated yny

11. Encryption Requirements RequirementDescriptionRegistrationSend eMDR Send eMD Support encryption of entire payload at point of creation - Content creator encrypts entire payloadnny (level2) Support encryption of components of payload at point of creation - Content creator encrypts portions of the payload nny (level 3) Support encryption of entire payload at send - Sender encrypts entire payloadnny Support encryption of components of payload at send - Sender encrypts portions of the payloadnny (level 2/3)

12. General Requirements CategoryRequirementDescriptionRegistrationSend eMDR Send eMD LocationSecurity elements are included in payload - Security elements are tied to payload and cannot be easily stripped away nny Existing Standard Created and maintained by SDO - Uses existing standardyyy Applicable Standard X12 274- Supports the exchange of provider information ynn Applicable Standard IHE HPD+- Supports the exchange of provider information ynn Applicable Standard X12 277- Supports the exchange of requests for additional information regarding a claim nyn Applicable Standard X12 275- Supports the exchange of additional information regarding a claim nny Applicable Standard HL7 CDA- Supports the exchange of patient clinical information nny

13. esMD Security Requirements Aligned to Standards by Use Case

14. Use Case 1: Requirements for Registration CategoryRequirementDSGX12 58WS- Security Metadata Extensions IdentityInclude Sender's public digital certificate in transaction y?yy IdentityInclude additional public digital certificates in transaction y?yy AuthenticityInclude one digital signature in transactionyyyy AuthenticityInclude additional digital signatures in transaction y2?yy AuthenticitySupports digital signature chains?2?yy AuthorityInclude multiple delegation of rights artifacts in transaction ynyy AuthoritySupports delegation of rights artifact chains?nyy Existing StandardCreated and maintained by SDO yyyn Applicable StandardX12 274 ?yyy Applicable StandardsIHE HPD+ ynyy

15. Use Case 2: Requirements for Sending eMDRs CategoryRequirementDSGX12 58WS- Security Metadata Extensions IdentityInclude Sender's public digital certificate in transaction y?yy AuthenticityInclude one digital signature in transactionyyyy Existing StandardCreated and maintained by SDOyyyn Applicable StandardX12 277?yyy

16. Phase 1: Requirements for Sending Electronic Medical Documentation CategoryRequirementDSGX12 58WS- Security Metadata Extensions IdentityInclude Sender's public digital certificate in transaction y?yy IdentityInclude additional public digital certificates in transaction y?yy AuthenticityInclude one digital signature in transactionyyyy AuthenticityInclude additional digital signatures in transaction y?yy AuthenticitySupports digital signature chains??yy AuthenticitySupports long term validation of digital signature y?yy AuthorityInclude multiple delegation of rights artifacts in transaction ynyy AuthoritySupports delegation of rights artifact chains?nyy EncryptionSupport encryption of entire payload at point of creation nnnn EncryptionSupport encryption of components of payload at point of creation nnnn EncryptionSupport encryption of entire payload at sendnyyn EncryptionSupport encryption of components of payload at send nyyn LocationSecurity elements are included in payload yynn Existing StandardCreated and maintained by SDO yyyn Applicable StandardX12 275 ?yyy Applicable StandardHL7 CDA ynyy

17. esMD Transaction Process Flow by Use Case

18. Use Case 1: Transaction Process Flow Registration Request Delegation of Rights Artifact Signature of Registration Request Public Certificate of Registration Requestor Assertion of Rights Signature of Assertion Public Certificate of Assertor Delegation of Rights Artifact Registration Request Message OwnerProcessPossible Locations and Standards Assertor of Rights Create Assertion Payload: SAML Sign Assertion Payload: DSG, CMS, XMLSig, C/XAdES Attach Public Certificate Payload: DSG, CMS, XMLSig, C/XAdES Provide Delegation of Rights Artifact to Registration Requestor Registration Requestor Create Registration Request Payload: X12.277, HPD Add Delegation of Rights Artifact Payload: X12.58?, MTOM Message Header: WS-Security, Metadata Sign Registration Request Payload: X12.58, MTOM Message Header: WS-Security, Metadata Attach Public Certificate Payload: X12.815?, MTOM Message Header: WS-Security, Metadata Send Registration Request Message Payer/Payer Contractor Trace Certificate of Registration Requestor to Root CA Verify Signature of Registration Request Verify Delegation of Rights Artifact Process Registration Request

19. Use Case 2: Transaction Process Flow eMDR Message eMDR Signature of eMDR Public Certificate of Payer/Payer Contractor OwnerProcess Possible Locations and Standards Payer/Payer Contractor Create eMDR Payload: X12.277 Sign eMDR Payload: X12.58 Message Header: WS-Security, Metadata Attach Public Certificate Payload: X12.815? Message Header: WS-Security, Metadata Send eMDR Message eMDR Consumer Trace Certificate of Payer/Payer Contractor to Root CA Verify Signature of eMDR Process eMDR

20. Phase 1: Transaction Process Flow Signed Medical Document Bundle eMDR Response Message eMDR Response Document Bundle Attachment Signature of eMDR Response Public Certificate of eMDR Consumer Medical Document Bundle Signature of Document Bundle Public Certificate of Document Bundle Owner OwnerProcess Possible Locations and Standards EHR/Provider Assemble Medical Document Bundle Payload: PDF, CDA, ZIP Sign Document Bundle Payload: DSG, C/XAdES Attach Public Certificate Payload: DSG, C/XAdES Provide Medical Document Bundle Attachment to eMDR Consumer eMDR Consumer Create eMDR Response Payload: X12.275, XD* Add Document Bundle Attachment Payload: MTOM Sign eMDR Response Payload: X12.58 Message Header: WS- Security, Metadata Attach Public Certificate Payload: X12.815? Message Header: WS- Security, Metadata Send eMDR Response Message Payer/Payer Contractor Trace Certificate of eMDR Consumer to Root CA Verify Signature of eMDR Response Process eMDR Response Consume Document Bundle

21. Appendix: Security Dataset Requirements for both Registering to Receive eMDRs & Sending eMDRs

22. Signature Artifact The Signature Artifact (paired with the Public Digital Certificate of the Sender) will enable the message receiver to authenticate the sender, verify message integrity, and prove non-repudiation. 1.Public Digital Certificate of Sender – x.509 certificate issued by a Certificate Authority 2.Signature Artifact – Encrypted hash of the message* * The exact details of the Signature Artifact are being developed in the esMD Author of Record Initiative.

23. Public Key of Dr. Smith Signature Artifact Example 1. Dr. Smith attaches signature artifact to Request to Register to Receive eMDRs Registration Request Provider Name: Dr. Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Dr. Smith checksum function Hash: 987654 signing algorithm Private Key of Dr. Smith 2. Payer verifies the Request came from Dr. Smith and has not been tampered with Registration Request Provider Name: Dr. Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Dr. Smith checksum function Hash: 987654 signing algorithm Verify Identity Hash: 987654 Verify Integrity

24. Delegation of Rights Artifact The Delegation of Rights Artifact (paired with the Public Digital Certificate of Subject) enables the Subject to delegate a right to the Sender of a Request such that the Receiver can cryptographically confirm that delegation of rights has occurred. 1.Public Digital Certificate of Subject – x.509 certificate issued by a Certificate Authority 2.Delegation of Rights Artifact – Encrypted hash of an assertion of rights* * The exact details of the Delegation of Rights Artifact are being developed in the esMD Author of Record Initiative.

25. Delegation of Rights Example (1/2) 1. Dr. Smith delegates the right to register his NPI to receive eMDRs to Medical Data, Inc. Registration Request Provider Name: Dr. Bob Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Medical Data, Inc. Delegation of Rights Artifact Public Digital Certificate of Dr. Smith 2. Medical Data, Inc. include their Signature Artifact, Dr. Smith’s Delegation of Rights Artifact, and both Public Digital Certificates in their Request to Register Dr. Smith to Receive eMDRs Assertion of Rights Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs. Expiration Date: 1/1/2013 Metadata Encrypted Hash: U37G90P checksum function Hash: 123456 signing algorithm Private Key of Dr. Smith

26. Delegation of Rights Example (2/2) Registration Request Provider Name: Dr. Bob Smith NPI: 987654 Service: Receive eMDRs Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Medical Data, Inc. Delegation of Rights Artifact Public Digital Certificate of Dr. Smith 3. Payer verifies Medical Data, Inc. has the right to register Dr. Smith to receive eMDRs Public Key of Dr. Smith Assertion of Rights Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs. Expiration Date: 1/1/2013 Metadata Encrypted Hash: U37G90P checksum function Hash: 123456 signing algorithm Hash: 123456 Verify Right