1 / 23

esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA

esMD Harmonization Use 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)

amena
Download Presentation

esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. esMD HarmonizationUse 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 eMDRobject 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

  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

  8. Additional Elements for Providers Focus on use of XD* metadata for data elements that help define providers and organizations

  9. Additional Elements for Providers Focus on use of XD* metadata for data elements that help define providers and organizations

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

  11. Additional eMDR Object Metadata 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 Focus on use of XD* metadata for data elements that help define the eMDR object attributes

  13. Additional eMDR External Objects 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

  17. eMDR – Documentation Return Requirements

  18. eMDR – Beneficiary Data

  19. eMDR– Claim Level Data

  20. eMDR– Line Level Data

  21. eMDR – Documentation Requested

  22. eMDR – Return Method

  23. Summary - XML vs CDA XML CDA Would allow for the reuse of a standard Would force the possible use of a newly defined document type • 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 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

More Related