1. esMD Harmonization Use 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 esMD Data ElementRecommendationExplanation Unique Registration Request 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). 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 esMD Data ElementObjectClassesGaps Provider Organization Object Organization HPDProvider HCRegulatedOrganization Signature Artifact Person/Role/Department Individual Provider Object organizationalPerson inetOrgPerson HPDProvider HCProfessional Signature Artifact Agent Object Organization HCRegulatedOrganization Signature Artifact Person/Role/Department Payer Organization Object Organization HCPayer Signature Artifact Person/Role/Department

10. Request/Response: Registration Request Information esMD Data ElementObjectClassesAttributeGaps NPI to registerHCRegulatedOrganization HCProfessional hcIdentifierMay need additional guidance regarding situations in which both Provider NPI and Organization NPI are included Alternate ID HCRegulatedOrganization HCProfessional hcIdentifier Service Support via extension to XD* metadata, or classCode slot Options Support via extension to XD* metadata, or options slot Request Type Support via extension to XD* metadata, contentType slot or Support via DSML Message type (addRequest, modifyRequest, modDNRequest, delRequest)

11. Request/Response Provider Directory Information esMD Data ElementObjectClassesAttributeGaps Provider Directory ID dnONeed to review with HPD Plus developer Provider Directory Address dnONeed to review with HPD Plus developer Unique Organization ID HCRegulatedOrganizationhcIdentifier Unique Provider ID HCProfessionalhcIdentifier ESI ID hpdHasAService ESI Integration Profile hpdHasAService

12. Response: Request Status esMD Data ElementObjectClassesAttributeGaps Unique Registration ID Support via SOAP Header or XD* metadata (uniqueID) Status Support via SOAP Header or limit to LDAP Result Codes (see RFC 2551) Failure Reason(s) Support via SOAP Header or limit to LDAP Result Codes (see RFC 2551) Pending Reason(s) Support via SOAP Header or limit to LDAP Result Codes (see RFC 2551)

13. Request/Response: Message Signature Approach 1 esMD Data ElementObjectClassesAttributeGaps Public Digital certificate of transmitter HCRegulatedOrganization HCPayer HCProfessional inetOrgPerson hcOrganizationCertificate hcSigningCertificate hcOrganizationCertificates hcSigningCertificate userCertificate userSMIMECertificate Support via IHE DSG See next slide. Signature Artifact Support via XD* metadata (hash) or Support via IHE DSG See next slide.

14. Request/Response: Message Signature Approach 2 esMD ObjectRecommendationExplanation Signature Object May prefer to support this object using 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.

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