1. HPD Updates By Eric Heflin, Co-Chair ITI PC CTO Texas Health Services Authority CTO/CIO The Sequoia Project

2. Proposed Work Item Title: HPD Updates and USA National Extension Proposal Editor: Eric Heflin Work item Editor: Eric Heflin Date: October 10, 2015 Version: 1.1 Domain: ITI

3. Updates Since Last Week I propose to remove CPs from the scope of this proposal and combine that with Lynn’s proposal I propose to break the remaining work up into to separate work items RESTful HPD USA National Extensions The remainder of the updated deck reflects this organization and moves the CP topic to the Appendix

4. Key Use Cases Same as HPD * Plus * Implementers in the USA Interoperability in USA is hindered by lack of specificity for USA-specific values Certificate discovery Implementers seeking a RESTful equivalent With only resource retrievals With dynamic query support

5. Problem Statement 1 (Revised) Problem 1: Need a USA national extension Required queries that must be supported Location and structure of key fields (Direct, SOAP end points, physician information such as DEA number and NPI) Impact: The optional attributes are actually required for many if not most real-world implementations of HPD, and the use of these attributes in the USA are not defined clearly, thus they are not interoperable Evidence of need: Real world implementations are expressing lack of interoperability and lack of clarity Value to IHE community: Resolving the above issues Ensuring interoperability with existing IHE profiles and other applicable standards

6. Discussion The IHE ITI “portfolio” of standards has a gap related to HPD Only about 50% of implementers needing to support cross- organizational directories have agreed to adopt HPD The remaining (based on conversations and email dialogs and surveys by the profile editor) implementers state that HPD has some remaining interoperability problems that have to be addressed or they will adopt “some other” directory standard. When pushed, they admit no other standard is ready, and they would like a USA version of HPD (my words) or a REST version (their words).

7. Problem Statement 2 (Revised) Problem 2: Need a RESTful version FHIR implementers rather wait and do nothing that adopt SOAP transports (their words) Current gap in the IHE portfolio of RESTful profiles Evidence of need: At least two implementations have already been created on non-standard approaches (a vendor involved in Argonaut, and Mirth which has open sourced their code) Impact: No solution exists based on standards If IHE doesn’t profile HPD using RESTful approaches, the need will likely be solved by someone else and it may not meet the needs of IHE implementers Value to IHE community: Resolving the above issues Ensuring interoperability with existing IHE profiles and other applicable standards

8. Committee Discussion Q&A Note next few slide provide more detail on needed clarifications and enhancements

9. Appendix

10. Problem Statement (CP topics) 1.ITI HPD has been adopted (18 organizations as per the IHE Product Registry) and we now have implementation experience 2.I conducted a survey via various email lists and to implementers (on April 30 th 2015 at 9:20am), asking for feedback on readiness of HPD to go to final text 3.Approximately 50% stated yes 4.Remainder stated significant problems exist that are preventing interoperability 5.Need to adopt CPs 1.Clarifying the structure of the directory 2.Clarify required vs. optional query parameter support (such as wildcard) 3.Others

11. Detailed of Needed Clarifications Secure email A secure email (Direct Project) address for an HCProfessional and/or HCRegulatedOrganization ‘mail’ vs. HPDElectronicService hpdServiceAddress? Missing ‘mail’ attribute for HCRegulatedOrganization At least two places where the secure email could reside one of which can also contain an URI such as for a SOAP end point Are any of these clarifications needed outside of the USA? TBD but I think it is possible that they are not USA-specific.

12. Detailed of Needed Clarifications HCProfessional.hcProfession error in link to NUCC code (does not exist) Is HCProfessional.hcIdentifier the location for the assigning authority and NPI number? Same for DEA number? HCProfessional.description has a cross reference to ProviderType which doesn’t provide needed info Same for HCRegulatedOrganization.hcIdentifier HCRegulatedOrganization.businessCategory has a bad link No definition of OrgType, even though it is referenced by HCRegulatedOrganization.description HPDProviderMembership requires use of optional (and undefined) extensions and is thus not interoperable Three different of variations of the HPD “control” extension xsi:type encoding have been found in the wild; HPD is not clear on which is correct. The variations don’t parse.

13. RESTful HPD Evidence of need At least two organizations have already written different version of a RESTful directory One based on an unknown approach One based on HPD and posted to GitHub https://github.com/mirthcorp/hpd-clienthttps://github.com/mirthcorp/hpd-client Argonaut identified a (assumed RESTful) directory as their 4 th priority for this release (but they are not working on it yet due to the other 3 priorities) and they are in requirements gathering mode for now Carequality “Initial Rollout” groups indicated they would rather exchange a custom file rather than adopt SOAP-based HPD for approximately 90% of the group Note that this “developer preference” of REST is deeper than SOAP vs. REST: They are also seeking to move aware from the LDAP-centric HPD syntax and semanitics

14. Detailed of other HPD CPs Diagrams conflict with the text in terms of cardinality and optionality Bad references to external links Definition of “R” is unclear (CP 766) Clarify top level organizations (CP 683) Inconsistent use of terminology in the profile as written now Schema Org Practice Address, Electronic Service URI, and Org Business Phone are all multi-valued fields with no constraints rendering them non-interoperable Clarify on the use of HPD for certificate discovery use case