security standards under review for esmd. transaction timeline an esmd transaction begins with the...

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 Systems

GatewayInternet

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 Requirements

Requirement Description Registration Send 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.

y y y

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.

y n y

Authenticity Requirements


Send eMD

Include one digital signature in transaction

- Sender signs message- Receiver uses digital signature to verify authenticity of message

y y y

Include additional digital signatures in transaction

- Content creators sign all or portion of payload- Receiver uses digital signatures to verify authenticity of content

y n y

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- Content creator adds time-stamped and CA signed OCSP response or CRL to content at time of creation

n n y

Authority Requirements


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

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

Supports delegation of rights artifact chains

- Receiver understands the order in which rights were delegated

y n y

Encryption Requirements


Send eMD

Support encryption of entire payload at point of creation

- Content creator encrypts entire payload n n y (level2)

Support encryption of components of payload at point of creation

- Content creator encrypts portions of the payload

n n y (level 3)

Support encryption of entire payload at send

- Sender encrypts entire payload n n y

Support encryption of components of payload at send

- Sender encrypts portions of the payload n n y(level 2/3)

General Requirements

Category Requirement Description Registration Send eMDR

Send eMD

Location Security elements are included in payload

- Security elements are tied to payload and cannot be easily stripped away

n 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 Registration

Category Requirement DSG X12 58 WS-Security

Metadata Extension

s

Identity Include Sender's public digital certificate in transaction

y ? y y

Identity Include additional public digital certificates in transaction

y ? y y

Authenticity Include one digital signature in transaction y y y y

Authenticity Include additional digital signatures in transaction

y 2? y y

Authenticity Supports digital signature chains ? 2? y y

Authority Include multiple delegation of rights artifacts in transaction

y n y y

Authority Supports delegation of rights artifact chains ? n y y

Existing Standard Created and maintained by SDO y y y n

Applicable Standard X12 274 ? y y y

Applicable Standards IHE HPD+ y n y y

Use Case 2: Requirements for Sending eMDRs


Metadata Extensions


y ? y y

Authenticity Include one digital signature in transaction y y y y

Existing Standard Created and maintained by SDO y y y n

Applicable Standard X12 277 ? y y y

Phase 1: Requirements for Sending Electronic Medical Documentation


Metadata Extensions


y ? y y

Identity Include additional public digital certificates in transaction

y ? y y

Authenticity Include one digital signature in transaction y y y yAuthenticity Include additional digital signatures in

transactiony ? y y

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

signaturey ? y y

Authority Include multiple delegation of rights artifacts in transaction

y n y y

Authority Supports delegation of rights artifact chains ? n y yEncryption Support encryption of entire payload at point

of creationn n n n

Encryption Support encryption of components of payload at point of creation

n n n n

Encryption Support encryption of entire payload at send n y y nEncryption Support encryption of components of payload

at sendn y y n

Location 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

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


Registration Request Message

Owner Process Possible 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

Use Case 2: Transaction Process Flow

eMDR Message

eMDR

Signature of eMDR

Public Certificate of Payer/Payer Contractor

Owner ProcessPossible Locations and

Standards


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

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 ProcessPossible 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


Trace Certificate of eMDR Consumer to Root CA

Verify Signature of eMDR Response

Process eMDR Response

Consume Document Bundle

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

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.

Public Key of Dr. Smith

Signature Artifact Example

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


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.

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 eMDRs

MetadataEncrypted 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 eMDRs

MetadataEncrypted 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. transaction timeline an esmd transaction begins with the...

Documents