1 / 15

esMD Harmonization Use Case 1: Initial Technical Approach HPD Plus

esMD Harmonization Use Case 1: Initial Technical Approach HPD Plus. Erik Pupo. Goals of Approach. Support multiple transport protocols to meet esMD requirements, including existing protocols already supported in Meaningful Use SOAP (Exchange) SMTP and SMIME (Direct)

cicada
Download Presentation

esMD Harmonization Use Case 1: Initial Technical Approach HPD Plus

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 1: Initial Technical Approach HPD Plus Erik Pupo

  2. Goals of Approach • Support multiple transport protocols to meet esMD requirements, including existing protocols already supported in Meaningful Use • SOAP (Exchange) • SMTP and SMIME (Direct) • XD* used to provide data sharing metadata • HPD Plus used for registration request and response provider information • Use additional infrastructure profiles for asserting identity, auditing and digital signatures, if required • 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 • Assume Internal Systems are capable of sending, receiving, and processing registration information aligned to HPD Plus, but not necessarily using an LDAP client or server • Wrap XD* metadata around a registration request or response document (transport-specific) • How does the data get there? • Use XD* to augment potential gaps in HPD Plus schema • Map data to HPD Plus for the registration request (content-agnostic) • What does the payer/payer contractor need to know to register a provider to receive eMDRs? • Map data to HPD Plus for the registration response (content-agnostic) • What does the provider need to know after attempting to register with a payer/payer contractor?

  4. Use of XD* for data sharing metadata • XD* profiles and associated metadata serve as possible candidate for data sharing metadata • XD* Metadata with SOAP or SMTP (push request and response from internal systems as XML aligned to HPD Plus) • See Harmonization presentation from 6/27 for details about XD* metadata

  5. Describing the Request/Response Message Use XD* metadata for data elements that help define the message. Additional metadata is supported or required by XD* profiles, such as Author and Intended Recipient. This may duplicate some information from payload.

  6. Background on HPD Plus • The HPD Schema extends LDAP organizationalUnit(OU) containers to organize information on Providers, including: • Healthcare Organization and Provider Identification, Demographics, Specializations, etc. • HPD Plus is an extension to HPD with additional entries to better support needs identified in the S&I Framework’s Provider Directory Initiative, including: • Electronic Service Information (ESI) • Provider Directory Information • Individual Provider and Organizational Provider relationships • A major difference between HPD Plus and LDAP is the requirement for a specific persistence mechanism. • LDAP requires an LDAP server for persistence. • HPD Plus decouples LDAP from a specific persistence mechanism. This allows, for example, an implementer to use a Relational Database model without an LDAP server.

  7. Background on DSMLv2 • Traditionally, LDAP was used in a client server environment • However, there is value in sharing directory information without an LDAP server. • DSMLv2 is a systematic translation of LDAP’s ASN.1 grammar into XML-Schema • Provides guidance on binding to SOAP or a simple data file • DSMLv2 represents the operations that an LDAP directory can perform and the results of such operations • DSMLv2 supports search, add, modify, delete, and extended request operations • esMD could use these operations to represent the Registration Request Type (new, update, terminate) • HPD/HPD Plus include guidance on using DSMLv2 and SOAP • The esMD registration request and response can use DSMLv2 to express an HPD Plus query or response as XML documents wrapped in XD* metadata.

  8. LDAP Terminology • An LDAP directory tree consists of related Entries • Entries are composed of one or more Object Classes • An Object Class is a collection of attributes • Attributes store data and define data type. • Each attribute has a name and belongs to an Object Class. • Object Classes define: • Whether an attribute it is mandatory (MUST) or optional (MAY) • The hierarchy of object classes and thus inheritance

  9. Request/Response: Provider Information

  10. Request/Response: Registration Request Information

  11. Request/Response Provider Directory Information

  12. Response: Request Status

  13. Request/Response: Message Signature Approach 1

  14. Request/Response: Message Signature Approach 2 Create an external object (which we would call a DSG document) that would be used to capture a digital signature and x.509 certificate.

  15. Summary of Analysis • HPD Plus, combined with XD* metadata and SOAP header, is capable of representing majority of the Use Case 1 data set requirements for the registration request • The addRequest, modifyRequest, modDNRequest, and delRequest result in an LDAPResult response which includes status codes for the request but no provider information • Possible to define extendedRequest specific to esMD needs • Need to clarify Signature Artifact requirements

More Related