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 1, 2015
Version: 1.1
Domain: ITI

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

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

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

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 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. Committee Discussion Q&A
Note next few slide provide more detail on needed clarifications and enhancements

8. Appendix

9. Detailed of Needed Clarifications
Secure
A secure (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 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.

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

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

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