esMD HarmonizationUse Case 2: Initial Technical Approach

XD* and CDA

Erik Pupo

Goals of Approach

• Support multiple transport protocols to meet esMD requirements, including existing protocols already supported in Meaningful Use– SOAP (Connect)– SMTP and SMIME (Direct)

• XD* used to provide data sharing metadata (see slide 3)• Examine multiple payload types, such as

– CDA (as structured document or attachment)– Custom XML as a formatting option– Examine HL7 and X12 messaging options (274 and 277)

• Use additional infrastructure profiles for asserting identity, auditing and digital signatures– IHE XUA (potential use of SAML as additional mechanism for identity – along with

X.509 certificates)– IHE DSG (to convey a signature)– IHE ATNA (for auditing)

Overview of approach

• Metadata around the eMDR object (transport-specific)– How does the data get there?

• Metadata for the eMDR object (content-agnostic)– What does the receiver need to know about the data?

• Structure of the eMDR object (payload-specific)– What is the actual data being transmitted?

• Establish underlying policy and trust model that assumes a certain level of “trust but verify”

Use of XD* for data sharing metadata

• After looking at the esMD data elements defined to date, XD* profiles and associated metadata serves as a possible candidate for data sharing metadata

• Purpose of this mapping is to look at evaluating support for esMD Data Elements in alignment to XD* metadata– XDS Metadata with SOAP (pull the eMDR object from a repository)– XDR Metadata with SOAP (push the eMDR object from internal

system)– XDR Metadata with SMTP (eMDR object is a structured XML

document – XDM Metadata with SMTP (eMDR object is an unstructured

attachment)

Outer Band – Describing the eMDR Object

esMD Data Element Recommendation ExplanationUnique eMDR Message ID Use uniqueId Globally unique identifier for the

submission-set instance assigned by the Document Source in OID format. Shall have a single value.

Timestamp Use submissionTime Point in Time at the Document Source when the Submission Set was created and issued for registration to the Document Registry. Shall have a single value.

This shall be provided by the Document Source (in case of e-mail with significant delay).

Provider Directory Objects – Assumptions

• A Provider Directory is queried for ESI as part of Use Case 2.• To support this, the Harmonization team will draft Provider Directory

implementation guidance to support esMD transactions for Provider and ESI information

Example – ESI and Provider DataesMD Object Recommendation Explanation

Payer Organization Object Author elements, to include authorInstitution

Payor organization information can be pulled from a provider directory

Payer Contractor Object Author elements, to include authorInstitution

To be further analyzed – this will depend on how the contractor information is classified within a directory

Provider Organization Object

intendedRecipient Provider organization information can be pulled from a provider directory

Individual Provider Object intendedRecipient An individual provider and their information can be pulled from the provider directory

Provider Organization Element Recommendation ExplanationOrganization Name intendedRecipient For an organization, the name can be

captured as part of the intendedRecipient

Address intendedRecipient

NPI intendedRecipient

Alternate ID (if no NPI) intendedRecipient intendedRecipient would support

Additional Elements for ProvidersesMD Data Element Recommendation Explanation

Person / Role / Department Represented within intendedRecipient

All of these metadata elements can be represented as part of XD* metadata (by extending the intendedRecipient slot to support further attributes and details)

Telephone Number Represented within intendedRecipient

Telephone Extension Represented within intendedRecipient

Email Represented within intendedRecipient

Fax Represented within intendedRecipient

URL Represented within intendedRecipient

Focus on use of XD* metadata for data elements that help define providers and organizations

Additional Elements for ProvidersesMD Data Element Recommendation Explanation

Address line 1 Represented within intendedRecipient

All of these metadata elements can be represented as part of XD* metadata (by extending the intendedRecipient slot to support further attributes and details)

Address line 2 Represented within intendedRecipient

City Represented within intendedRecipient

State Represented within intendedRecipient

ZIP Code Represented within intendedRecipient

ZIP Code Extension Represented within intendedRecipient

Focus on use of XD* metadata for data elements that help define providers and organizations

eMDR Object Metadata

eMDR Object Element Recommendation ExplanationUnique ID for eMDR Object uniqueID Globally unique identifier for the

submission-set instance assigned by the Document Source in OID format. Shall have a single value.

Unique ID for original eMDR Object uniqueID Under XD* this is a specific transaction where the original object is “deleted”

Timestamp of eMDR Object submissionTime Point in Time at the Document Source when the Submission Set was created and issued for registration to the Document Registry. Shall have a single value.This shall be provided by the Document Source (in case of e-mail with significant delay).

Focus on use of XD* metadata for data elements that help define the eMDR object attributes

Additional eMDR Object MetadataesMD Data Element Recommendation Explanation

Due Date Define a dueDate element XDS can support this extension as an attribute

The objective would be to represent this element as part of the transaction

Request Purpose Two ways to implement:

• Purpose of use can be expressed through use of XUA metadata

• Purpose of use can be expressed as an XD* Metadata attribute

• PurposeOfUse slot would be created

XDS can support this extension as an attribute.

Alternatively, we can exchange the purpose of use using XD* metadata, as done in the esMD Exchange Specification.

Focus on use of XD* metadata for data elements that help define the eMDR object attributes. In this case, we may also use XUA metadata.

Additional eMDR Object MetadataesMD Data Element Recommendation Explanation

Request Type Use contentTypeCode The code specifying the type of clinical activity that resulted in placing these XDS Documents in this XDS-Submission Set. These values are to be drawn for a vocabulary defined by the XDS Affinity Domain. Shall have a single value.

Request Type Reason Use comments Comments associated with the Submission Set. Free form text with an XDS Affinity Domain specified usage.

Focus on use of XD* metadata for data elements that help define the eMDR object attributes

Additional eMDR External ObjectsesMD Object Recommendation Explanation

Signature Object Recommendation to support this object is to use IHE DSG Profile to create signature document

Will develop an example to explore with workgroup

To support this recommendation, we need to pinpoint specifically where a signature is needed in each transaction.

Public Digital certificate of transmitter

There are 2 options here:

• Include the cert in DSG signature document and include the DSG document in transactions

• Send the certificate as part of the transaction

Either separate exchange of the certificate can be supported to assert identity or we can include the certificate as part of the DSG document

Create an external object (which we would call a DSG document) that wouldbe used to capture a digital signature and x.509 certificate.

esMD Representation Options

• When viewing the eMDR object data elements, we focused on analyzing whether the Clinical Document Architecture (CDA), through an existing or newly defined Document Type, could support specification of the eMDR object, or whether a custom XML format was needed

• The eMDR object would include various pieces of information– Claims Related Information– Provider Directory/ESI Location– Provider Directory/ESI Information– eMDR object

• Beneficiary• Claim• Line

– Signature object• Use a DSG document with an X.509 signature

Summary of Analysis

• After close review of the CDA R2 structure, it was determined that while many of these elements could be represented in a CDA R2 document, a custom XML format might be preferable:– One reason to use CDA, for example, would be make claims

level data persistent and available for future usage.• Use of CDA in this case would support persistence of the data, in

combination with use of XD* profiles• The issue would be maintaining meaning among the data elements

expressed– ASC X12N 277 transactions can also be represented within the

custom XML format.

eMDR – Request InformationeMDR Data Element Recommendation Explanation

Date of Request Unclear if this can be represented in CDA Since this is an element describing the eMDR object, we would not want to represent this in CDA.

Cover Letter text Can be included as custom XML or as part of a CDA nonXML Body

Included as attachment or unstructured body

Program Can be included as part of CDA R2 Header Include as part of organization

Person / Role / Department Can be included as part of CDA R2 Header All of these can be expressed as part of a CDA document type.

Telephone Number Can be included as part of CDA R2 Header

Telephone Extension Can be included as part of CDA R2 Header

Email Can be included as part of CDA R2 Header

Fax Can be included as part of CDA R2 Header

URL Can be included as part of CDA R2 Header

eMDR – Documentation Return Requirements

eMDR Data Element Recommendation ExplanationDue Date Represent as part of XD* metadata This is best to represent as part of

data sharing metadata that is sent as part of a transaction

Provider Directory Address Represent as part of XD* metadata This is best to represent as part of data sharing metadata that is sent as part of a transaction

Provider Directory ID Represent as part of XD* metadata This is best to represent as part of data sharing metadata that is sent as part of a transaction

Return Method Object Represent as custom XML format See eMDR Return Object

Claim Processor Identifier TBD – it is not clear if this can be represented in CDA

eMDR – Beneficiary DataeMDR Data Element Recommendation Explanation

Beneficiary Name Can be included in CDA R2 Header Akin to the patient, which can be defined in the CDA R2 Header

Date of Birth Can be included in CDA R2 Header Also can be included in the CDA R2 Header

Account Number Can be included in CDA R2 Header A number of this type can be represented in the CDA R2 Header

Medical Record Number Can be included in CDA R2 Header A number of this type can be represented in the CDA R2 Header

Payer Identifier for the Policy holder

This linkage cannot be created in the CDA

After examining what this data element is trying to define, it was determined that this type of identifier could not be directly placed in a CDA document type.

Payer Identifier for Beneficiary Can be included within a CDA Document Type

A number of this type can be represented in the CDA R2 Header

eMDR – Claim Level DataeMDR Data Element Recommendation Explanation

Date Claim Received Unclear if this can be represented in CDA

Since this is an element describing the eMDR object and an external dependency, we would not want to represent this in CDA.

Date(s) of Service Included in CDA as part of ServiceEvent

Can also be represented in XD* metadata

The <serviceEvent> element describes the activity being documented. When combined with effectiveTime, this would give dates of service.

Type of Bill Can be expressed in the CDA Document Type

Would need to be drawn from either Admission Source or Discharge Disposition information

Place of Service Can be expressed in the CDA Document Type

Would need to be drawn from either Admission Source or Discharge Disposition information

Diagnosis Code(s) Included in CDA as part of code element

Diagnosis can be defined in the CDA as an observation element

Diagnosis Code Set Used Included in CDA as part of codeSystem element

Diagnosis can be defined in the CDA as an observation element

Diagnosis Related Group Code

DRG would not be explicit in a CDA document

A DRG code would have to typically be identified by linking to a CPT code and then map that to MS-DRG/APC

eMDR – Line Level DataeMDR Data Element Recommendation Explanation

Performing Provider NPI Supported through CDA

Performing Provider Alternate ID

Supported through CDA

Alternate ID Type Supported through CDA

Date(s) of Service Attached to ServiceEvent Use effectiveTime to denote dates of service

Place of Service Attached to ServiceEvent Can use information about where a procedure occurred to define place of service

Revenue Code Unclear where to place in CDA NUBC codes can be supported within CDA but it is not clear exactly where to place this element in a CDA Document Type

Provider Specialty Supported in CDA

Diagnosis Code Supported in CDA As noted, diagnosis can be defined using an observation element

Procedure Code Supported in CDA through Procedure section

Can be included in a CDA procedure section

Procedure Modifier(s) Supported in CDA through Procedure Code hierarchy

Can be included in a CDA procedure section

eMDR – Documentation RequestedeMDR Data Element Recommendation Explanation

Documentation Requested Supported in CDA if a corresponding LOINC document type can be defined

LOINC Document Types allow for support of additional document types.

This list of document types can be further constrained as part of esMD

Description of Documentation Requested

Supported in CDA Included with the document type

eMDR – Return MethodeMDR Data Element Recommendation Explanation

Return Method(s) Not fit for inclusion in CDA Not clear how to represent a method in the content of an object

Electronic Service Information (Electronic Service Information Object)

Not fit for inclusion in CDA CDA would not be a good fit for including an ESI

Physical Return Address Not fit for inclusion in CDA While a physical address could be expressed in CDA, it is not clear that this element can be separated from other elements

Maximum Electronic Return Size per transaction

Not fit for inclusion in CDA Not clear how to represent a size for a return object within the CDA

Return Constraints Not fit for inclusion in CDA

Return Format(s) Not fit for inclusion in CDA Format would be clear from the format returned

Summary - XML vs CDA

XML• XML would provide greater

flexibility for representation of various data elements

• XML would cause a “loss of standardization” as the format used would be specific to esMD

CDA• Would allow for the reuse of a

standard • Would force the possible use

of a newly defined document type

Linkage of XD* Metadata to CDA and XML• Inclusion of XD* metadata will allow for the linking of the custom XML

object to metadata attributes • XDSSubmissionSet metadata• XDSDocumentEntry metadata