Reminder: Do not include any PHI or PII in Confluence. If you require 508 accessibility assistance or any other support for this system, then please send an email to onc-jira-questions@healthit.gov
ONC’s Shared Nationwide Interoperability Roadmap discussed provider directories and the broader topic of resource location as a priority in Section M, Health Care Directories and Resource Location.
There was no specific plan to align the Workshop discussion with the call to action in the Interoperability Roadmap. However, concepts found in the Interoperability Roadmap that were discussed during the Workshop.
Interoperability Roadmap Concept | Provider Directory Workshop Discussion |
---|---|
Short-term, search for a provider’s Direct address | This was identified by the Workshop as a priority use case. |
Long-term, search for the electronic service information of all participants that support patient discovery | Other ESI info was considered a priority use case with the acceleration of CommonWell and Carequality pushing this to a more near-term priority. The group did not consider this long-term. |
Federated, modular directory options are key. Decentralized administration in order to operate efficiently and remain accurate and up-to-date. | Some support for the federated model; however, there was a large emphasis on needing a single source of truth and a push for NPPES to fulfill that role. However, there was also recognition that NPPES has legal limitations on the data it can store and provide, so it is unlikely to be a single source of data for all use cases, necessitating standards to enable sharing provider data across systems. |
How does an individual or system place a query to discover participants of a learning health system or the services they offer? How is API information passed back? How does one know that the response is complete? | The group leaned toward the use of FHIR APIs to query provider directories, and dropping the use of HPD for querying. The FHIR API has been built up by MiHIN, and the FHIR Argonaut group is picking it up to finish the IG. They believe the IG will be released in a month or so. |
How does an individual or system gain access to resource location services? How is one authenticated to access directories or resource location services? | Authentication was briefly discussed, particularly OAuth. But this is still a question that needs to be answered. |
How is information in resource location services managed and updated and how is the information curated to ensure accuracy? | This was discussed repeatedly, but there weren’t necessarily standard answers. There is a push for NPPES to be the source of data, and for CMS to use regulatory authority to compel providers to keep their information up to date. A few states already have such a requirement, but there is no standard or motivation for most providers to update their data on a regular basis. There are mixed state laws on single credentialing processes. |
How does an individual or system find information regarding the relationships between organizations and providers? | This was not specifically discussed, except as it related to a few use cases that require this connection. |
How does an individual or system find information regarding when an organization changes its name, merges with another organization or establishes additional locations? | Individuals pushed for NPPES to be the source of truth for this information. |
Near-term Milestone: A glide path for moving from current provider directories to future resource location techniques is developed via a public transparent process, and widely disseminated. | It seemed like there was agreement in the room that using FHIR APIs to enable the interoperability of provider directories is the path forward. The FHIR APIs would allow for discovery of more than just providers, as they are designed to discover multiple types of resources. No official glide path was discussed. |
Provider directory operators should align existing directories to the extent possible with best available standards for provider directories as identified in ONC’s most recent finalized Interoperability Standards Advisory or with emerging RESTful approaches if implementation timelines are not near-term. | When the Roadmap was released, it was envisioned that this would be HPD. However, there was agreement that the focus should not be on the internal standards an organization uses for a provider directory (i.e. LDAP), but rather focuses on the use of a single standard to enable the exchange of provider directory information. There was agreement that the FHIR APIs being developed by the Argonaut group could serve this function and be ready in the near-term. |
The FACAs should assess the critical health care directory questions identified in the roadmap and how current standards and/or legacy services already incorporated into products can be used or extended to support stakeholder needs. | Not discussed |
As an interim step, ONC will work with health IT stakeholders to encourage uptake of current provider directory activities. | When the Roadmap was developed, it was envisioned that this would be HPD. However, adoption of the standard is lower today than it was last year. It appears that HPD is not the option. For example, California had 8 organizations participating last year and now only has 2. MiHIN has begun using the FHIR specs for directory access, though it’s not clear how mature these standards are yet. The FHIR standard should be ready at the end of May for testing. |
Through public, transparent processes, stakeholders should prioritize the participants and services that are to be discoverable using resource location and identify a near-term goal for the first small set of resources to be included in initial implementations, such as Direct addresses, electronic service information, web addresses, and multiple practice locations. | The group started to prioritize use cases, which would help with this prioritization. The top two priorities were discovering Direct addresses and discovering ESI. Also high on the list were care coordination requirements, such as referral loops, transitions of care, etc. |
CMS should, via various policies, require that Direct addresses and electronic service information are entered into and maintained in NPPES. | This was removed from the Meaningful Use final rule. Individuals were pushing CMS to include this in upcoming rulemaking, such as MACRA. |
CMS will continue to support efforts to ensure that health plan provider directories are made electronic and published according to best available national standards to support learning health system resource location. | Updates to NPPES, including an API and the addition of identifier fields, like Direct Address. There was a strong push in the room for NPPES to play a larger role as a source of truth, including a push to change regulations to allow them to collect and distribute additional data elements. |
ONC and other certification bodies will determine how to support provider directories through certification processes. | Not discussed |
Directories should encompass both real-time and bulk queries. | Not discussed |
Most important focus in defining the architecture for resource location is how information will be managed, updated, and kept accurate. | This was discussed frequently during the meeting. There was a push from some that federal and state regulation should be used to compel providers to update their data on a set basis. |