security standards under review for esmd

Security Standards under Review for esMD

Transaction TimelineAn 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 Systems Gateway

Message Received

Process Header

Process Payload

X12 58 Signature

WS-Security

CAQH CORE/ XD* Metadata

Process Content

DSG Signature

Internal SystemsGatewayInternet

Store Content

IHE DSGThe 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

Extensions to MetadataThis 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


X12 58This 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.



WS-SecurityThis 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.



esMD Security Requirements

Identity RequirementsRequirement Description Registration Send

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

y y y

Include additional public digital certificates in transaction

- Transaction includes public digital certificates of all other parties that have digitally signed something in the transaction.- Receiver traces certificates to root CAs in order to verify identity of all parties that have digitally signed something in the transaction.- Receiver uses public keys and digital signatures to verify authenticity of all parties that have digitally signed something in the transaction.- Receiver uses certificates to verify all delegation of rights artifacts created by all parties that have digitally signed an assertion

y n y

Authenticity Requirements 1/2Requirement Description Registration Send

eMDRSend eMD

Digital Signature of portion of transaction (message)

- All parties that interact with transaction can sign it - Receiver uses digital signature to verify authenticity of message across all hops

n n n

Digital Signature of entire transaction (message)

- Sender of message can sign it - Receiver uses digital signature to verify authenticity of message

y y y

Digital Signature of a contributor to a document (payload)

- Multiple content creators sign relevant portions of payload- Receiver uses digital signatures to verify authenticity of content

n n Level 1 - nLevel 3 - y

Digital Signature of an entire document (payload)

- Single content creator signs entire payload- Receiver uses digital signatures to verify authenticity of content

n n Level 1 - nLevel 2 - y

Digital Signature of an aggregation of documents (payload)

- Single content creator signs entire payload- Receiver uses digital signatures to verify authenticity of content

n n Level1 - y

Authenticity Requirements 2/2Requirement Description Registration Send

eMDRSend eMD

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

y n y

Supports long term validation of digital signatures

- Receiver can validate digital signature up to twenty years after signing- Example: Content creator adds time-stamped and CA signed OCSP response or CRL to content at time of creation

n n y

Authority RequirementsRequirement Description Registration Send

eMDRSend 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

n n n

Include multiple delegation of rights artifacts in transaction

- Party A delegates a right to Party B who may delegate that right to Party C

y n y

Encryption RequirementsRequirement Description Registration Send

eMDRSend eMD

Support encryption of components of payload at point of creation

- Content creator encrypts portions of the payload

n n Level 1 - n Level 3 - ?

Support encryption of entire payload at point of creation

- Content creator encrypts entire payload n n Level 1 - nLevel 2 - ?

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

General RequirementsCategory Requirement Description Registration Send

eMDRSend eMD

Location Security elements are included in payload

- Security elements are tied to payload and will be processed by internal systems rather than gateway

y (Delegation of Rights)

n y

Existing Standard

Created and maintained by SDO

- Uses existing standard y y y

Applicable Standard

X12 274 - Supports the exchange of provider information

y n n

Applicable Standard

IHE HPD+ - Supports the exchange of provider information

y n n

Applicable Standard

X12 277 - Supports the exchange of requests for additional information regarding a claim

n y n

Applicable Standard

X12 275 - Supports the exchange of additional information regarding a claim

n n y

Applicable Standard

HL7 CDA - Supports the exchange of patient clinical information

n n y

esMD Security Requirements Aligned to Standards by Use Case

Use Case 1: Requirements for RegistrationCategory Requirement DSG X12 58 WS-

SecurityMetadata Extension

sIdentity Include Sender's public digital certificate in

transactionn ? y y

Identity Include additional public digital certificates in transaction

y ? y y

Authenticity Supports digital signature chains ? 2? y y

Authenticity Digital Signature of entire transaction (message)

n n y n

Authority Include multiple delegation of rights artifacts in transaction

y n ? y

Authority Supports delegation of rights artifact chains ? n ? yExisting Standard Created and maintained by SDO y y y nApplicable Standard X12 274 ? y y yApplicable Standards IHE HPD+ y n y yLocation Security requirements are included in

payloady y? n y

Use Case 2: Requirements for Sending eMDRs

Category Requirement DSG X12 58 WS-Security

Metadata Extensions

Identity Include Sender's public digital certificate in transaction

y ? y y


n n y n

Existing Standard Created and maintained by SDO y y y nApplicable Standard X12 277 ? y y y

Phase 1: Requirements for Sending Electronic Medical Documentation

Category Requirement DSG X12 58 WS-Security

Metadata Extensions

Identity Include Sender's public digital certificate in transaction

y ? y y

Identity Include additional public digital certificates in transaction

y ? y y

Authenticity Supports digital signature chains ? ? y yAuthenticity Supports long term validation of digital

signaturey ? y y


n n y n

Authenticity Digital Signature of an aggregation of documents (payload)

y y/n y/n y/n

Authority Include multiple delegation of rights artifacts in transaction

y n ? y

Authority Supports delegation of rights artifact chains ? n ? yLocation Security elements are included in payload y y n nExisting Standard Created and maintained by SDO y y y nApplicable Standard X12 275 ? y y yApplicable Standard HL7 CDA y n y y

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

Comparison of Security Standards under Review for esMD

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

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

X12 58Strengths- 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

WS-SecurityStrengths- 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

Security Approach 1Message• 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 Assertions for 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

esMD Transaction Process Flow by Use Case

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

Owner Process Standards

Registration Requestor

Request Delegation of Rights Artifact from Assertor of Rights • SAML Query

Assertor of Rights

Create Assertion • SAML

Sign Assertion and attach certificate • XMLSig

Provide Delegation of Rights Artifact to Registration Requestor • SAML Response

Registration Requestor

Create Registration Request • Payload: X12.274, HPD

Attach Delegation of Rights Artifact and attach Certificate of Subject

• Payload: MIME Attachment of Signed SAML Assertion

Sign Registration Request Message and attach certificate

• NwHIN/CORE Message: WS-Security

• DIRECT Message: S/MIME

Send Registration Request Message • NwHIN/CORE• Direct

Payer/Payer Contractor

Trace Certificate of Registration Requestor to Root CA



Verify Signature of Registration Request• NwHIN/CORE Message: WS-

Security• DIRECT Message: S/MIME

Verify Delegation of Rights Artifact • Payload: MIME Attachment of Signed SAML Assertion

Process Registration Request • Payload: X12.274, HPD

Use Case 2: Transaction Process Flow

eMDR Message

eMDR

Signature of eMDR

Public Certificate of Payer/Payer Contractor

Owner Process Standards


Create eMDR • Payload: X12.277

Sign eMDR Message and attach certificate



Send eMDR Message • NwHIN/CORE• Direct

eMDR Consumer

Trace Certificate of Payer/Payer Contractor to Root CA



Verify Signature of eMDR• NwHIN/CORE Message: WS-


Process eMDR • Payload: X12.277

Phase 1: Transaction Process FlowSigned 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

Owner Process Possible Locations and Standards

EHR/Provider

Assemble Medical Document Bundle • Payload: PDF, CDA, ZIP

Sign Document Bundle • Payload: DSG

Attach Public Certificate • Payload: DSG

Provide Medical Document Bundle Attachment to eMDR Consumer • Outside esMD scope

eMDR Consumer

Create eMDR Response • Payload: X12.275, XD*

Add Document Bundle Attachment • Payload: BIN Seg, Attachment

Sign eMDR Response and attach certificate



Send eMDR Response Message • NwHIN/CORE• Direct


Trace Certificate of eMDR Consumer to Root CA



Verify Signature of eMDR Response• NwHIN/CORE Message: WS-


Process eMDR Response • Payload: X12.275, XD*

Consume Document Bundle • Payload: DSG

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

Signature ArtifactThe 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.

Public Key of Dr. Smith

Signature Artifact Example1. Dr. Smith attaches signature artifact to Request to Register to Receive eMDRs


Provider Name: Dr. SmithNPI: 987654Service: Receive eMDRs

MetadataEncrypted Hash: H8K9QTPPublic 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


Provider Name: Dr. SmithNPI: 987654Service: Receive eMDRs

MetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Dr. Smith

checksum function Hash: 987654

signing algorithm

Verify Identity

Hash: 987654

Verify Integrity

Delegation of Rights ArtifactThe 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.

Delegation of Rights Example (1/2)1. Dr. Smith delegates the right to register his NPI to receive eMDRs to Medical Data, Inc.


Provider Name: Dr. Bob SmithNPI: 987654Service: Receive eMDRsMetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Medical Data, Inc.Delegation of Rights ArtifactPublic 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

MetadataEncrypted Hash: U37G90P

checksum function Hash: 123456 signing algorithm

Private Key of Dr. Smith

Delegation of Rights Example (2/2)


Provider Name: Dr. Bob SmithNPI: 987654Service: Receive eMDRsMetadataEncrypted Hash: H8K9QTPPublic Digital Certificate of Medical Data, Inc.Delegation of Rights ArtifactPublic 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

MetadataEncrypted Hash: U37G90P

checksum function Hash: 123456

signing algorithm Hash: 123456

Verify Right

security standards under review for esmd

Documents