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

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

Problem Statement ITI HPD has been adopted (18 organizations as per the IHE Product Registry) and we now have implementation experience I conducted a survey via various email lists and to implementers (on April 30th 2015 at 9:20am), asking for feedback on readiness of HPD to go to final text Approximately 50% stated yes Remainder stated significant problems exist that are preventing interoperability

Problem Statement (cont.) Issues stated by potential implementers Need to adopt CPs Clarifying the structure of the directory Clarify required vs. optional query parameter support (such as wildcard) Others 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) 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 Bottom line is that the optional attributes are required for real-world implementations of HPD, and those attributes are not defined, thus they are not interoperable

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

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).

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

Appendix

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.

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.

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-client Argonaut identified a (assumed RESTful) directory as their 4th 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

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