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