esmd harmonization use case 2 initial technical approach xd and cda n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA PowerPoint Presentation
Download Presentation
esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA

Loading in 2 Seconds...

play fullscreen
1 / 23

esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA - PowerPoint PPT Presentation


  • 129 Views
  • Uploaded on

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)

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'esMD Harmonization Use Case 2: Initial Technical Approach XD* and CDA' - amena


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
goals of approach
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
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
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)
provider directory objects assumptions
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
additional elements for providers
Additional Elements for Providers

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

additional elements for providers1
Additional Elements for Providers

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

emdr object metadata
eMDR Object Metadata

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

additional emdr object metadata
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.

additional emdr object metadata1
Additional eMDR Object Metadata

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

additional emdr external objects
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.

esmd representation options
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
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.
summary xml vs cda
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