UDDI+HPD+Working+Group

= = = =
 * Nationwide Health Information Network UDDI/HPD (+) Working Group**


 * Purpose**

The Nationwide Health Information Network UDDI/ HPD (+) (Universal Description Discovery and Integration/ Healthcare Provider Directory) Working Group's goal was to identify the requirements for the standard for the next version of the Exchange Web Services Registry.


 * The Universal Description Discovery and Integration** is the current standard utilized by the Registry. It is an Extensible Markup Language (XML) - based registry, which was included in the Web Service Interoperability (WS-I) standard. Its purpose is for the publication and discovery of Web services implementations within and between enterprises (1).


 * The Healthcare Provider Directory (HPD ) profile** is an Integrating the Healthcare Enterprise (IHE) standard, and is a possible new standard for the next version of the Exchange Web Services Registry. This technology supports queries against, and the management of, healthcare provider information that may be publicly shared in a directory structure. HPD directory structure is a listing of the following two categories of healthcare providers that are classified by provider type, specialties, credentials, demographics and service 130 locations.

1) Individual Provider – A person who provides healthcare services, such as a physician, nurse, or pharmacist. 2) Organizational Provider – Organization that provides or supports healthcare services, such as hospital, Healthcare Information Exchange (HIE), Managed Care, Integrated Delivery 135 Network (IDN), and Association (2).

**The Healthcare Provider Directory Plus (HPD+) profile** outlines how the HPD profile can be expanded for use with the S&I Provider Directory data model. It is expected that the HPD Data model as implemented in LDAP will eventually be upgraded to S&I compliance, though this could take some time. HPD can be adapted to use a Relational Database (RDB) persistence model, and not rely on an LDAP server. This can be done with a few constraints, but without changes to the HPD wsdl and the DSMLv2 xml schema found in the technical spec. This type of implementation is called HPD Plus RDB (3).

The group's goal is to evaluate the ability of the two technologies to meet the current requirements set forth by the Web Services Registry, and adopt the technology that is most realistic for the community to use with respect for backwards compatibility, adoptability and interoperability.


 * Meetings**

As of 3/20/2012 the meetings of this workgroup have been suspended until further notice, per agreement of the workgroup members.


 * Main Work Product**

The main output of this working group was a spreadsheet detailing the requirements a technology must meet, and the ability of the current standard of the Exchange Web Services Registry (WSR), UDDI and the forthcoming standard, HPD (+), to meet these requirements.The far right columns, WSR (i.e. the current standard), HPD and HPD + are the different technologies and whether or not the technology supports that requirement- a N signifies NO and a Y signifies YES.

Spreadsheet (downloadable version available ): Team Members & Process
 * || //Problem Statement// ||  ||   ||   ||   ||   ||
 * || The current standard utilized by the Exchange Web Services Registry (WSR), UDDI, has been identified as a waning standard. ||  ||   ||   ||   ||   ||
 * || //Objective// ||  ||   ||   ||   ||   ||
 * || To identify the requirements for the standard of the next version of the Exchange Web Services Registry. ||  ||   ||   ||   ||   ||
 * || //Considerations// ||  ||   ||   ||   ||   ||
 * || UDDI has been identified as 'end of lifing' and new enhancements need to be addressed in the replacement solution. ||  ||   ||   ||   ||   ||
 * || Does UDDI need to be replaced as a standard? ||  ||   ||   ||   ||   ||
 * || These requirements may be used in the future roadmap. ||  ||   ||   ||   ||   ||
 * || Perspective is currently from the consumer's viewpoint. ||  ||   ||   ||   ||   ||
 * || Where do the data governance considerations need to be addressed? ||  ||   ||   ||   ||   ||
 * || Operational migration considerations from contract to contract. ||  ||   ||   ||   ||   ||
 * || Maintain compatibility with the current S&I Framework Provider Directory initiative. ||  ||   ||   ||   ||   ||
 * //ID// || //Requirement// || Importance || WSR || HPD || HPD+ || Comments ||
 * 1 || Supports Federation - information contained in multiple places and query is routed by the query responder to all appropriate places (not replicated data). ||  || N || Y || Y || Federation in this respect - UDDI does not support. ||
 * 2 || Identify all service providers servicing a given city. ||  || N || Y || Y || We can support through additional tmodels. ||
 * 3 || Identify all service providers servicing a given state ||  || Y || Y || Y ||   ||
 * 4 || Identify all service providers servicing a given zip code ||  || N || Y || Y || We can support through additional tmodels. ||
 * 5 || Retain the ability to store the same discrete data elements as are contained within WSR today. ||  || Y || N* || N || *For HPD, a nested model would support this. ||
 * 6 || Remain compatible with existing WSR interfaces in the network. ||  || Y || N || N || For HPD, a nested model would support this. ||
 * 7 || Enumerate all services available at a homeCommunity ID. ||  || Y || Y || Y ||   ||
 * 8 || Enumerate all home community IDs within the registry/directory. ||  || Y || Y* || Y* || * Note: Our group would need to identify the string that denotes a homeCommunity ID. HPD can enumerate identifiers by type to fulfill this requirement. ||
 * 9 || Identify all versions of a specific service for a homeCommunity ID. ||  || Y || N* || Y || *For HPD, a nested model would support this. ||
 * 10 || Locate a specific version of a service for a homeCommunity ID. ||  || Y || *N || Y || *For HPD, a nested model would support this. ||
 * 11 || Identify ALL home community IDs that implement a specific service. ||  || Y || *N || Y || *For HPD, a nested model would support this. ||
 * 12 || Identify ALL home community IDs that implement a specific version of a service. ||  || Y || *N || Y || *For HPD, a nested model would support this. ||
 * 13 || Identify contact information (name, phone, fax, email, physical address) for a homeCommunity ID. ||  || Y || Y || Y || WSR only supports one generic context per homecommunity ID. ||
 * 14 || Support replicated data to enable scaling. ||  || Y ||   ||   || Unknown for HPD / HPD+. ||
 * 15 || Vendor adoption of the underlying technology (UDDI for WSR, LDAP for HPD). ||  || N || Y || Y ||   ||
 * 16 || Ability to differentiate between organizations and individuals. ||  || N || Y || Y ||   ||
 * 17 || Identify associations between exchange gateways and locations or facilities. ||  || N || Y || Y ||   ||
 * || //Assumptions:// ||  ||   ||   ||   ||   ||
 * || The terms referenced in this document are presently being used in the context of an HIE. ||  ||   ||   ||   ||   ||
 * || The candidates considered here are based off of the work from the S&I Provider Directory initiative. ||  ||   ||   ||   ||   ||
 * 16 || Ability to differentiate between organizations and individuals. ||  || N || Y || Y ||   ||
 * 17 || Identify associations between exchange gateways and locations or facilities. ||  || N || Y || Y ||   ||
 * || //Assumptions:// ||  ||   ||   ||   ||   ||
 * || The terms referenced in this document are presently being used in the context of an HIE. ||  ||   ||   ||   ||   ||
 * || The candidates considered here are based off of the work from the S&I Provider Directory initiative. ||  ||   ||   ||   ||   ||
 * || The terms referenced in this document are presently being used in the context of an HIE. ||  ||   ||   ||   ||   ||
 * || The candidates considered here are based off of the work from the S&I Provider Directory initiative. ||  ||   ||   ||   ||   ||

The workgroup consists of multiple technology Subject Matter Experts (SMEs), people representing federal agencies, and the Specifications Factory team. The group works in a collaborative consensus-based approach to develop its recommendations.


 * Other Materials related to the UDDI/HPD Workgroup**

In addition to the main product (above), the workgroup has created the following materials:
 * //Type of Material// || //Material// || //Use of Material// ||
 * LDAP/HPD Data Element Mapping || [[file:LDAP&HPD.Data Element Mapping.2011.12.14.pptx]] || Onboarding- LDAP / HPD ||
 * Statewide Send and Receive Technical Specifications Appendix || [[file:Statewide Send Receive Technical Specifications Appendix -HPDPlus Implementation Guide_v1.pdf]] || Onboarding- HPD within S&I ||
 * Meeting Minutes (2.28.2012) || [[file:2.28 UDDI HPD Spec factory Meeting Minutes.docx]] || To become familiarized with the specific, low-level issues the Working Group dealt with. ||
 * Meeting Minutes (3.6.2012) || [[file:3 6 12 UDDI HPD Spec factory Meeting Minutes.docx]] || To become familiarized with the specific, low-level issues the Working Group dealt with ||
 * Meeting Minutes (3.20.2012) || [[file:3 20 12 UDDI_HPD+ Spec Factory WG.docx]] || To become familiarized with the specific, low-level issues the Working Group dealt with ||
 * Data Mapping || [[file:HPDPlusV3.docx]] || Individual, Organization, Individual-Organization, Credential, Electronic Services ||
 * Data Mapping || [[file:Data Element Mapping Master Spreadsheet FINAL.XLS]] || Larger Scope Data Mapping ||

Sources: (1) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=uddi-spec (//2//) http://www.ihe.net/Technical_Framework/upload/IHE_ITI_Suppl_HPD_Rev1-1_TI_2010-08-10.pdf (3) http://exchange-specifications.wikispaces.com/file/view/Statewide+Send+Receive+Technical+Specifications+Appendix+-HPDPlus+Implementation+Guide_v1.pdf