Day 1 included presentations on the current state of the dominant open technical standards for interoperable provider directories, including:

  • Universal Discovery and Description Interface (UDDI)
  • Healthcare Provider Directory (HPD)
  • Clinical Services Discovery (CSD)
  • FHIR® (Fast Healthcare Interoperability Resources) Practitioner and Organization resources

Day 2 included a critical discussion concerning future development priorities and adoption of technical standards.
Some of the most important discussion points are listed below.

  • UDDI is an Internet standard for discovering web services developed by OASIS. It is not widely implemented or adopted, even outside of healthcare. Development of UDDI has been discontinued by its standard development organization.
    • UDDI was adopted as the specification for the Service Registry for eHealth Exchange as the only open standard available that met the needs at the time. Even at the time of its selection, a migration to an alternative to UDDI was envisioned.
  • HPD provides a rich data model for individual and organizational providers, their relationships, and the means to exchange health information with them. The HPD API is based on SOAP web services and a Directory Services Markup Language (DSML) interface to a data model based on Lightweight Directory Access Protocol (LDAP). The HPD specification is managed as a profile by Integrating the Healthcare Enterprise (IHE). The profile is in turn based on Internet and HL7 standards.
    • A US National Extension to the international HPD standard has begun to add necessary attributes (e.g.., NPI) and use cases (e.g., electronic service discovery) required for the US market.
  • Oregon, California, and Michigan have interoperable provider directories based (at least in part) on HPD.
    • California has implemented and operates a federated statewide provider directory based on the HPD data model and API. However, vendor support for HPD has decreased since 2015, and a transition to a new federated approach is anticipated in 2016.
    • Michigan has based many of the provider attributes in its provider directory on the HPD data model, but has implemented and published a RESTful API to HPD rather than support the SOAP and DSML web service in the HPD specification.
  • The HPD specification has suffered from a confusing and conflicting version history. Workshop participants believe that its data model, based on LDAP, and its interface, based on DSML, have created a cumbersome API for real-world applications.
    • Workshop participants that have implemented HPD stated that they have learned much from it. The HPD data model or at least the data attributes within HPD were considered a good description of those required for provider directories. Several participants recommended that HPD’s data model should be retained or at least be considered for the basis of future standards development and implementation efforts.
  • CSD supports many of the data attributes in HPD, but without a data model based on LDAP or an API based on DSML. The CSD specification is managed as a profile by IHE, based on Internet and HL7 standards.
    • CSD has not be implemented or adopted anywhere in the US, but is used extensively in Africa.
  • FHIR is a RESTful API describing a large collection of resources that are designed to address the interoperability and data needs of healthcare. An API to provider directory information is supported primarily through the Practitioner and Organization resources, and perhaps the Location resource (which describes individual facilities). The FHIR standard is managed by HL7.
    • FHIR is seen as the future for interoperable health IT systems.
    • While the FHIR Practitioner and Organization resources are often described as a FHIR-based provider directory, participants noted that FHIR specifies a framework for an API. Practitioner and Organization are not components of a provider directory but potential components of an API to a provider directory.
    • FHIR Practitioner and Organization resources may not support a way to communicate all of the complex relationships required for provider directories, and do not include the attributes required for health plan participation or for electronic service endpoints for exchange.
    • Development and demonstration of FHIR capabilities has been accelerated by the Argonaut Project. However, the Argonaut Project did not prioritize provider directories until early 2016, and little progress had been made by the time of the Workshop.
    • Michigan has developed and published an API based on extensions to the FHIR Practitioner and Organization resources.
  • Participants in eHealth Exchange and early participants in Carequality have voiced a very strong preference that the directories that support those programs not be based on the HPD API. They prefer to wait for a provider directory API specification or implementation guide based on the FHIR framework.
    • At the Workshop, members of the Argonaut Project committed to prioritizing development of an implementation guide for provider directories, perhaps by the May FHIR Connectathon for consideration in the HL7 ballot cycle for the next Draft Standard for Trial Use (DSTU 3).
    • Some participants at the Workshop stated that if an implementation guide for provider directories was available by early or mid-2016, they would adopt it. Some stated that they were dropping their current support for the HPD API in favor of an API based on FHIR.
  • It was unclear to Workshop participants how a broader collection of stakeholders could become engaged or support development of a FHIR implementation guide, either through the Argonaut Project or through HL7.

The overall sentiment of discussions on Day 2 was that stakeholders were generally discontinuing support for the HPD API in favor of an API based on FHIR, and were committed to advancing FHIR support for provider directories to meet industry needs in 2016. However, there needed to be a means for broader stakeholder input to insure that a FHIR implementation guide for a provider directory API met use case requirements. Many strongly advocated retaining the HPD data model as the underlying directory for which FHIR might provide an API.

See Appendix F, Provider Directory Workshop Materials, for more detail on the presented material and Workshop discussions, including a recording and draft transcript of the discussions of support for FHIR as an API standard to be adopted for provider directories on Day 2.

Navigation

  • No labels