1 / 34

Security Standards under Review for esMD

Security Standards under Review for esMD. Transaction Timeline. CAQH CORE Metadata. CAQH CORE/ XD* Metadata. X12 58 Signature. WS-Security. WS-Security. X12 58 Signature. DSG Signature. XD* Metadata. Encryption (transport level). DSG Signature. Content packaged into payload.

kalona
Download Presentation

Security Standards under Review for esMD

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Standards under Review for esMD

  2. Transaction Timeline CAQH CORE Metadata CAQH CORE/ XD* Metadata X12 58 Signature WS-Security WS-Security X12 58 Signature DSG Signature XD* Metadata Encryption (transport level) DSG Signature Content packaged into payload Message created Message Sent Message Received Process Header Process Payload Process Content Store Content Electronic Content Created Content Stored as a document Internal Systems Internal Systems Gateway Internet Gateway 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.

  3. IHE DSG Transaction Structure 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

  4. Extensions to Metadata Transaction Structure 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

  5. X12 58 Transaction Structure 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

  6. WS-Security Transaction Structure 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

  7. esMD Security Requirements

  8. Identity Requirements

  9. Authenticity Requirements 1/2

  10. Authenticity Requirements 2/2

  11. Authority Requirements

  12. Encryption Requirements Note: esMD assumes transport level encryption is in place. Payload encryption is still under consideration

  13. General Requirements

  14. esMD Security Requirements Aligned to Standards by Use Case

  15. Use Case 1: Requirements for Registration

  16. Use Case 2: Requirements for Sending eMDRs

  17. Phase 1: Requirements for Sending Electronic Medical Documentation

  18. Conclusions • No single standard/specification supports all requirements for all use cases • Support for some requirements depends on implementation details • Example: WS-Security can sign an entire message or a portion of a message, including the payload. However, this signature would usually be processed by the SOAP gateway and unavailable to the internal information systems. • A mix of standards may be required, each one selected to fulfill a specific requirement

  19. Comparison of Security Standards under Review for esMD

  20. IHE DSG • Strengths • Supports transmission of signatures and certificates • Based on XMLSig and XAdES which provides long-term validation of signatures • Can be used to sign any kind of document • XML transforms are not required • Signatures applied to payload and processed by internal system • Potentially meets AoR Level 2 requirements • Weaknesses • Receiver must track both signed document and signature document • Applicability limited to signing of documents • Probably does not meet AoR Level 3 requirements

  21. Extensions to Metadata Strengths Potentially designed to meet exact needs of esMD Signatures applied to payload and processed by internal system Weaknesses Requires changes to existing standards Relevant SDOs may choose to not adopt changes Cannot sign entire SOAP message Alternatives MIME Attachments: Attach various security artifact files to payload using appropriate MIME content-type

  22. X12 58 • Strengths • Standard across all X12 transactions • Applies signature at payload level • Weaknesses • Only applicable to X12 transactions • Requires separate transaction to exchange certificates • Requires maintenance of certificates apart from transaction • No support for Delegation of Rights

  23. WS-Security • Strengths • Supports transmission of signatures and certificates • Easily supported in all SOAP based transactions • Based on XMLSig standard • Can support XAdES which provides long-term validation of signatures • Supports exchange of SAML Assertions(for Delegation of Rights) • Weaknesses • Signatures are applied to message and processed at gateway • Gateway would require additional configuration to pass signatures, certificates, and SAML Assertions to internal system • No definitive specification binding SOAP over SMTP for Direct purposes • Alternatives • S/MIME: Default signing and encryption of Direct messages

  24. Security Approach 1 • Message • NwHIN/CORE: WS-Security to sign message and transmit certificate used to sign message • Optional: Gateway passes security tokens to internal information system • Direct: S/MIME to sign message and transmit certificate used to sign message • Payload • IHE DSG to sign document bundle • NwHIN/CORE: ZIP file containing document bundle and signature document placed in 275 BIN segment • Direct: ZIP file containing document bundle and signature document sent as attachment to payload • Additional security elements sent as attachments to payload • Delegation of Rights: Signed SAML Assertion file attached as MIME content-type text/xml • Public Certificates: Certificate file (PEM, DER, PKCS12, PKCS7) attached as appropriate MIME content-type application/x-pkcs____ • Strengths • Uses existing standards • Supports transmission of signatures and certificates • All signatures based on XMLSig standard • Supports XAdES signature on document bundle, which provides for long-term validation of signature • Supports exchange of SAML Assertionsfor Delegation of Rights • Gateway processes message signature • Internal system processes document bundle signature, delegation of rights artifact, and any additional certificates • Does not preclude use of X12 58 if required by trading partners • Weaknesses • Combines multiple specifications instead of using single specification for all security requirements • Receiver must maintain attachments and track relationships between files • Approach is not completely transport neutral

  25. esMD Transaction Process Flow by Use Case

  26. Use Case 1: Transaction Process Flow Delegation of Rights Artifact Signature of Registration Request Public Certificate of Registration Requestor Delegation of Rights Artifact Registration Request Message Signature of Assertion Registration Request Public Certificate of Assertor Assertion of Rights

  27. Use Case 2: Transaction Process Flow eMDR Message Signature of eMDR Public Certificate of Payer/Payer Contractor eMDR

  28. Phase 1: Transaction Process Flow Signed Medical Document Bundle Signature of Document Bundle eMDR Response Message Public Certificate of Document Bundle Owner Signature of eMDR Response Medical Document Bundle Public Certificate of eMDR Consumer Document Bundle Attachment eMDR Response

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

  30. 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. Public Digital Certificate of Sender – x.509 certificate issued by a Certificate Authority Signature Artifact – Encrypted hash of the message* * The exact details of the Signature Artifact are being developed in the esMD Author of Record Initiative.

  31. Signature Artifact Example Private Key of Dr. Smith Registration Request Provider Name: Dr. Smith NPI: 987654 Service: Receive eMDRs checksum function Hash: 987654 signing algorithm Metadata Encrypted Hash: H8K9QTP Public Digital Certificate 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 checksum function Hash: 987654 Verify Integrity signing algorithm Hash: 987654 Metadata Encrypted Hash: H8K9QTP Public Digital Certificate of Dr. Smith Public Key of Dr. Smith 1. Dr. Smith attaches signature artifact to Request to Register to Receive eMDRs Verify Identity

  32. 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. Public Digital Certificate of Subject – x.509 certificate issued by a Certificate Authority 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.

  33. Delegation of Rights Example (1/2) Private 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 checksum function Hash: 123456 signing algorithm Metadata Encrypted Hash: U37G90P 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 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 1. Dr. Smith delegates the right to register his NPI to receive eMDRs to Medical Data, Inc.

  34. Delegation of Rights Example (2/2) 3. Payer verifies Medical Data, Inc. has the right to register Dr. Smith to receive eMDRs 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 Assertion of Rights Dr. Bob Smith gives Medical Data, Inc. the right to register his NPI to receive eMDRs. Expiration Date: 1/1/2013 checksum function Hash: 123456 Metadata Encrypted Hash: U37G90P Hash: 123456 signing algorithm Verify Right Public Key of Dr. Smith

More Related