1. esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA Erik Pupo

2. 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)

3. 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”

4. 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)

5. Outer Band – Describing the eMDR Object esMD Data ElementRecommendationExplanation Unique eMDR Message ID Use uniqueIdGlobally unique identifier for the submission-set instance assigned by the Document Source in OID format. Shall have a single value. Timestamp Use submissionTimePoint 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).

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

7. Example – ESI and Provider Data esMD ObjectRecommendationExplanation 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 intendedRecipientProvider organization information can be pulled from a provider directory Individual Provider Object intendedRecipientAn individual provider and their information can be pulled from the provider directory Provider Organization ElementRecommendationExplanation Organization Name intendedRecipientFor an organization, the name can be captured as part of the intendedRecipient Address intendedRecipient NPI intendedRecipient Alternate ID (if no NPI) intendedRecipientintendedRecipient would support

8. Additional Elements for Providers esMD Data ElementRecommendationExplanation 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

9. Additional Elements for Providers esMD Data ElementRecommendationExplanation 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

10. eMDR Object Metadata eMDR Object ElementRecommendationExplanation Unique 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 uniqueIDUnder 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

11. Additional eMDR Object Metadata esMD Data Element RecommendationExplanation Due Date Define a dueDate elementXDS 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.

12. Additional eMDR Object Metadata esMD Data ElementRecommendationExplanation Request TypeUse contentTypeCodeThe 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 ReasonUse commentsComments 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

13. Additional eMDR External Objects esMD ObjectRecommendationExplanation 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 would be used to capture a digital signature and x.509 certificate.

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

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

16. eMDR – Request Information eMDR Data ElementRecommendationExplanation Date of Request Unclear if this can be represented in CDASince 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 HeaderInclude as part of organization Person / Role / Department Can be included as part of CDA R2 HeaderAll 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

17. eMDR – Documentation Return Requirements eMDR Data ElementRecommendationExplanation Due Date Represent as part of XD* metadataThis 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* metadataThis 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* metadataThis 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 formatSee eMDR Return Object Claim Processor Identifier TBD – it is not clear if this can be represented in CDA

18. eMDR – Beneficiary Data eMDR Data ElementRecommendationExplanation Beneficiary NameCan be included in CDA R2 HeaderAkin to the patient, which can be defined in the CDA R2 Header Date of BirthCan be included in CDA R2 HeaderAlso can be included in the CDA R2 Header Account NumberCan be included in CDA R2 HeaderA number of this type can be represented in the CDA R2 Header Medical Record NumberCan be included in CDA R2 HeaderA 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 BeneficiaryCan be included within a CDA Document Type A number of this type can be represented in the CDA R2 Header

19. eMDR – Claim Level Data eMDR Data ElementRecommendationExplanation 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 ServiceIncluded in CDA as part of ServiceEvent Can also be represented in XD* metadata The element describes the activity being documented. When combined with effectiveTime, this would give dates of service. Type of BillCan be expressed in the CDA Document Type Would need to be drawn from either Admission Source or Discharge Disposition information Place of ServiceCan 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 UsedIncluded 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

20. eMDR – Line Level Data eMDR Data ElementRecommendationExplanation Performing Provider NPISupported through CDA Performing Provider Alternate ID Supported through CDA Alternate ID TypeSupported through CDA Date(s) of ServiceAttached to ServiceEventUse effectiveTime to denote dates of service Place of ServiceAttached to ServiceEventCan use information about where a procedure occurred to define place of service Revenue CodeUnclear where to place in CDANUBC codes can be supported within CDA but it is not clear exactly where to place this element in a CDA Document Type Provider SpecialtySupported in CDA Diagnosis CodeSupported in CDAAs noted, diagnosis can be defined using an observation element Procedure CodeSupported 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

21. eMDR – Documentation Requested eMDR Data ElementRecommendationExplanation 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 CDAIncluded with the document type

22. eMDR – Return Method eMDR Data ElementRecommendationExplanation Return Method(s) Not fit for inclusion in CDANot clear how to represent a method in the content of an object Electronic Service Information (Electronic Service Information Object) Not fit for inclusion in CDACDA would not be a good fit for including an ESI Physical Return Address Not fit for inclusion in CDAWhile 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 CDANot 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 CDAFormat would be clear from the format returned

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