FHIR Chat · Provider Directory

I am looking for a Provider Directory. We want to be able to search for a provider by specialty, healthcare organization, NPI, first, last, ... for purposes of Referral and Admissions. What are people using?

Grahame Grieve (Oct 14 2016 at 19:21):

Are you aware of the argonaut provider directory project?

Radu Craioveanu (Oct 14 2016 at 19:40):

hi Grahame. I just looked at the provider directory on Argonaut. Is it implemented by anyone and if so, what are they using for the data? Their own healthcare provider data, or are they fronting something like this https://npiregistry.cms.hhs.gov/registry/? with a FHIR facade.

Grahame Grieve (Oct 14 2016 at 19:56):

their own data. Suggest you subscribe to the argonaut project email list and track the developement fo the project (or ask questions there)

Radu Craioveanu (Oct 14 2016 at 19:58):

I am on the Argonaut Google group? Is that what you are referring to?

Grahame Grieve (Oct 14 2016 at 19:59):

yes it was

Brian Postlethwaite (Oct 15 2016 at 00:14):

This is an active group at the moment. There are some doing this as a centralized installation (such as the Michigan Health Information Network) and there are also products (like Epic/Cerner/Surescript/others) that are exposing their internal directory data for this purpose.
The ONC also has a community working on developing the use cases in this space and fostering the wider community to be collaborative here. There has been discussions in this context on potentially exposing NPI/NPPES as a FHIR service, but nothing at present.

John Moehrke (Oct 19 2016 at 15:55):

The argonaut directory work is being proposed to be made international and normative in IHE. This as a FHIR alternative to HPD/SDC profiles that exist using older technology. Discussion is ongoing this week, for next year.

Brian Postlethwaite (Oct 19 2016 at 21:19):

This directory work at the Argonaut group is also getting good focus from the ONC's Healthcare Directory Technology Learning Community.
(Important to note that it is no longer being called a provider directory but a Healthcare directory, as it is not just providers that are exposed via the direcory - recognising the importance of services and supporting health activies, not just a list of providers)

Brett Marquard (Oct 20 2016 at 01:45):

Thanks John, Where is the discussion in IHE occurring? Just curious what the overlap is with the folks involved in the argonaut PD efforts.

John Moehrke (Oct 20 2016 at 14:12):

The discussion in IHE is just starting in the ITI committee where prior directory work was done. @Eric Heflin proposed it as a work item for 2017. We just finished the prioritization phase, for which this proposal got high priority. Next week we assess resource availability. The expectation is NOT to compete, but be a place where the good work can be promulgated and maintained. Eric assured us that he and others will do this coordination to assure alignment and separation of responsibilities.

nicola (RIO/SS) (Oct 21 2016 at 15:03):

We are working on support NPI registry in a FHIR format. There are some questions:

how to interpret identifiers (other_provider_identifier_[x])
where to put state in identifier (extension?)
where to save licence number
where to put nucc taxonomy

Brian Postlethwaite (Oct 24 2016 at 00:19):

These will belong in either the Practitioner.Identifier or Practitioner.Role.Identifier (or the new PractitionerRole resource) depending on if the identifier is unique to the practitioner, or the practitioner at a specific location/role.
Licenses could be stored in the practitioner qualification.identifiers, as these are not typically location specific, and do not necessarily mean that the practitioner can perform services they have a license for at all locations they work. (As may not be employed for those services ).

nicola (RIO/SS) (Oct 24 2016 at 05:22):

Thank you, Brian

Sandeep Giri (Jan 19 2017 at 00:47):

California State Bill (SB) 137 requires providers must share specific attributes on each practitioner (see https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=201520160SB137 ) - some of these (e.g. whether a practitioner is accepting new patients, insurance plans they accept, specifics of their licenses, i.e. licensing state, license number, what hospital admitting privileges they have, etc) are not explicitly defined as attributes in Practitioner resource. Would you recommend that we create extensions in Practitioner to represent these, or is there a better alternative to represent these?

Sandeep Giri (Jan 19 2017 at 01:04):

As a follow up to separate chats I had with @Paul Knapp @Lloyd McKenzie and @Brian Postlethwaite during San Antonio Connectathon : What are some practical ways to associate a Practitioner resource with insurance plans they accept?

Currently there isn't a resource that represents an insurance plan. There is Coverage, but it is specific to a Patient. We need a way to represent that a Practitioner takes Blue Cross Blue Shield's plan X, Y, and Z, Aetna's plan A and B, and so on. A common use case is that a patient would want to search for practitioners that have a particular specialty, accept the patient's insurance plan, and are located nearby (within X miles) of where the patient lives.

Lloyd suggested we can perhaps use the Contract resource to represent insurance plans accepted by an Organization (so any Practitioner providing service under that Organization is assumed to accept such plans). However, an Insurance plan isn't really a contract, and at the same time, I'm not sure if this is enough to require creating a new resource to represent Insurance plans.

Thoughts?

John Moehrke (Jan 19 2017 at 03:04):

What kind of metadata is necessary to describe these insurance plans well enough to search? I agree that Contract is not likely the right object. Might be a useful reason to create a new Resource type.

Lloyd McKenzie (Jan 19 2017 at 03:27):

Well, you don't actually want the "plan", you want the agreement between an organization and an insurer that the organization will offer services under the plan and the insurer will cover services delivered under the plan by that organization. Which is sort of contract-like. The plan itself would presumably just be referenced by identifier/code

Patrick Werner (Jan 19 2017 at 13:40):

I agree with Lloyd, it's an agreement between an insurer and a praticioner in a organisation. A practicioner could work in different organisations (eg hospital, and his own doctors office.) with different agreements with different insurers.

Sandeep Giri (Jan 19 2017 at 18:13):

Thanks John, Lloyd, and Patrick.

@Lloyd McKenzie - to represent an insurance plan, we'd at least need 2 attributes - 1. organization that provides the plan (e.g. Kaisier, Bluecross Blueshield,Cigna, etc.); and 2. the organization-specific name of the plan (e.g. Bronze 60 HMO, Gold PPO, etc.).

With your suggested structure, separate Contract resources will need to represent a provider organization's agreement with Kaiser, Cigna, etc. respectively (each also defined as a Organization), and within each Contract, use an attribute like valueItem.entity to represent the different insurance plan names? Actually then the names of the plans will need to be defined as a CodeableConcept, which is good, because then the Practitioner search parameters can reference the same CodebleConcept. Does this approach make sense?

I'm sure definition of an insurance plan requires other attributes to, like plan start/end date (valid for), geographic areas covered, plan type (HMO vs PPO, etc.), and cost attributes such as yearly deductible, OOP max, etc. for individual/family (although our use case to search for a provider by insurance plan they accept doesn't need these). I suspect that for these latter attributes, we may need to consider a separate InsurancePlan type resource.

Brian Postlethwaite (Jan 20 2017 at 17:03):

I dont think a contract s the correct resource either. Its some simple searching attributes that I think belong with the organization. This could be a valid use for the upcoming orgassociation resource. But there is nothing there today specifically for it.
Valid usecase that we do plan to cover, and we will work on this soon - happy to have the implementer to assist directly.
@Jeff Eastman , do you have this data in your directory, I don't recall.

Sandeep Giri (Jan 21 2017 at 18:31):

Sorry to repost, but wanted to recheck if there's any feedback on this:

Brian Postlethwaite (Jan 22 2017 at 23:06):

I'll have a look throught that list of things to work out how to represent these in the STU3 spec.
There will be further work done on the Practitioner Qualifications/certifications post STU3 release, but we will be indicating how to support these with the current STU3 work, which is where the Provider Directory work is being modelled, and is anticipated being used.

Samantha Mater (Apr 21 2017 at 15:48):

Is there a specific operation or parameter combination that would be called to download an entire provider directory using FHIR?

Additionally, if a location/organization links a specialty to a specific direct address, is there a way to represent that relationship in FHIR?

Lloyd McKenzie (Apr 21 2017 at 18:53):

Just do a GET on /Practitioner with no filters (though you may need to do 2 GETs if you want Organizations too.). Look at HealthcareService if you're wanting to provide contact information for a specific capability within an organization/location.

Abbie Watson (Apr 25 2017 at 14:49):

Are there any urls of ProviderDirectories that we can sync up with? We just got Meteor on FHIR passing the Touchstone ProviderDirectory test scripts, and would like to try to hydrate the system.

Radu Craioveanu (Apr 26 2017 at 16:38):

We are looking at doing Provider Referrals and Provider lookups. We think we will use the current FHIR Provider Resource and tie it to the CMS / NPPES API. What are some of the more curated sources people are using for this purpose. Any help is much appreciated.

John Moehrke (Apr 26 2017 at 16:45):

There is joint work between ONC, Argonaut, and IHE. to Profile a Provider Directory. http://build.fhir.org/ig/argonautproject/provider-directory/

Radu Craioveanu (Apr 26 2017 at 16:46):

Thanks, will look into that.

Radu Craioveanu (Apr 28 2017 at 02:28):

@John Moehrke , do you know of anyone that created an implementation around this specification?

John Moehrke (Apr 28 2017 at 11:11):

I have no experience with the ONC or Argonaut side of this; I have been involved in IHE side. IHE has just started their work. This week is the IHE workgroup meeting where we worked on this, should be a public comment period in May.

Dave Carlson (Apr 28 2017 at 15:43):

Look at the connectathon track from Jan 2017, and a similar track the previous meeting. You might contact a few of the participants and look at the connectathon spreadsheet for server implementations. I know that Epic had something running at the connectathon. http://wiki.hl7.org/index.php?title=201701_Provider_Directories_and_Scheduling

Mario Hyland (Jun 19 2017 at 15:13):

Any updates on Provider Directory by the community? Just posted a thread over on the IHE Stream - to the same effect. Where is Provider Directory IG, Profiles, etc work currently being done? We are working with the HL7 FHIR Connectathon Track Leadds for Scheduling - who use case incorporates Provider Directory. If we can get updated Provider Directory efforts publically accessible and reviewed prior to Sept - we can work on updates, and rolling out any new Test Scripts to support Provider Directory. We want to support both FHIR PD Consumer, and PD Host services.

Stefan Lang (Jun 19 2017 at 15:31):

@Mario Hyland There is the current draft of the IHE mCSD profile (I believe that's what John talked about above): http://ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_mCSD_Rev1.0_PC_2017_05-17.pdf
Comment period has just closed last Friday.

John Moehrke (Jun 19 2017 at 15:34):

Thanks Stefan... correct -- I responded to Mario over on the IHE thread (he is making me feel like a dog chasing my tail) --- That would be for the 'classic' for for HPD. I presume you are interested in the FHIR form for HPD -- which is renamed "Mobile Care Services Discovery" (mCSD). This rename because for the FHIR form we combined CSD and HPD; the CSD editors showed up to the face-to-face meeting, and thus they got to pick the name of the combined profile.. :-) The public comment form is at http://www.ihe.net/Public_Comment/#IT

Mario Hyland (Jun 19 2017 at 16:35):

Sorry @John Moehrke - trying to get everyone connected to this topic and work stream "connected" :) - appreciate the link - are comments published (or IHE Private)? I was wondering if anyone from the Argonaut project submitted comments?

John Moehrke (Jun 19 2017 at 17:18):

IHE is an open-process. However the comment deadline just happened, so they have not yet been brought together comprehensively. This will be done over the coming week, and disposition will happen. You can join IHE mailing lists, and follow their FTP... FREE.

Elliot Silver (Jun 19 2017 at 18:56):

Further to what John wrote, although the deadline has passed, please feel free to submit comments. If they are too late for this cycle, we can try to integrate them into a later cycle, or as a CP if appropriate.

Mario Hyland (Jun 19 2017 at 20:09):

@Elliot Silver I realize that efforts are underway with IHE, and similarily there have been work products and efforts underway with HSPC, Argonauts and the large FHIR Community. There have been a few HL7 FHIR Connectathons which have focused on PD as part of another test track Scheduling. Ensuring we capture the correct use cases, it should be easy for these groups to review how the IHE draft standard would apply to their efforts. While IHE references the FHIR Resources, do you know if any work is currently underway to constrain the HL7 FHIR Resources with FHIR Profiles? Currently, many are leveraging Furore Simplifier and Forge tools (see @Michel Rutten for further information) - while @Richard Ettema and AEGIS work to create FHIR Test Scripts to test FHIR implementations.

Elliot Silver (Jun 19 2017 at 20:23):

At this time, the IHE documentation process does not use Structure Definition, CapabilityStatement, or ImplmentationGuide. We're aware of Simplifier and Forge, and @Michel Rutten did a great presentation of them for the IHE. I would like to see that change, but it is going to take some work to get there. The more people we have in committees who are willing to do the work, the quicker we can switch. Trust me, we are aware of this gap.
A more immediate concern for me is getting feedback on whether mCSD is compatible with the other provider directory efforts. We'd hoped to get committe feedback on that, but it doesn't appear to have been done. I'd be grateful if someone with knowledge of the other directory efforts was able to provide input, in whatever form.

Mario Hyland (Jun 19 2017 at 21:05):

Likewise, we would like for the threads on this topic to find multual common ground to form a basis to build on. Are you the IHE lead on this effort?

Elliot Silver (Jun 19 2017 at 21:14):

Mario, I'm co-chair of the IHE commitee responsible for mCSD; and I'm on the IHE task force looking at general FHIR issues. @Luke Duncan is the profile author for mCSD. Speaking for Luke, I'll say either of us would be happy to receive any feedback provided.

Fred Trotter (Jun 15 2019 at 19:50):

Hello, and thanks for your collective work on FHIR. I have been watching from the sidelines with enthusiasm. I have some comments on the Provider Directory standard here: http://www.fhir.org/guides/argonaut/pd/ I am. currently trying to reconcile the real-world role of NPPES and this standard. And part of the problem with this is that the use cases listed on that page for provider directory are, not actually use cases, but functions. Use cases typically include the reasons why someone needs a functionality, as well as documenting the functionality. The functionality listed there could be summarized as "search for and get provider data". But full use cases should include. "transmit the data required to enable finding provider data in order to support the routing of healthcare data to them" and "transmit data needed for determining the appropriateness/credentials/specialty and availability of a provider for a potential patient referral" or "transmit the data that allows patients to find doctors in order to make appointments" and "providing data for researchers to be able to study providers". Those are the reasons that search is necessary and should be included in the use cases on those page. Without those it is impossible to determine if NPPES should be a compliant provider directory because the "real" reasons that an HL7 FHIR Provider Directory should exist are not actually listed. Is this something that can be easily corrected? These concepts are included in the discussions from the 2016 provider directory workshop as well as use cases outlined in the IHE provider directory specification... so I hope that it is reasonable to surface these. Frankly it would be enough to add the sentence "the purpose of the provider directory is to facilitate further interoperability efforts and the study thereof". But it even missing something that high-level.

Grahame Grieve (Jun 15 2019 at 19:57):

@Daniel Chaput @Brian Postlethwaite

Josh Mandel (Jun 15 2019 at 20:33):

http://build.fhir.org/ig/HL7/VhDir/ is probably the most relevant recent effort btw @Fred Trotter . http://build.fhir.org/ig/HL7/VhDir/general-guidance.html provides context and a bit of the use case flavor you're asking about here.

Josh Mandel (Jun 15 2019 at 20:34):

(This is the "continuously integration" build for that guide; under active development.)

Fred Trotter (Jun 15 2019 at 21:56):

Brilliant. My problem is solved.

Brian Postlethwaite (Jun 16 2019 at 02:54):

If you log a tracker through the link on the core spec I'll make sure those cases are also described in there too.

Fred Trotter (Jun 16 2019 at 15:02):

Applied for access to gforge.hl7.org which I assume is the write place to make such a ticket.

Fred Trotter (Jun 16 2019 at 15:27):

Ok, next question. I have credentials that I have found in NPPES that are not found in the current credential list.
http://hl7.org/fhir/v2/0360/2.7/index.html
and
http://hl7.org/fhir/v2/0360/2.7/v2-0360-2.7.cs.json.html
Also, the current credential list lacks any url to the manager of the credential. For instance, a CHT - Certified Hand Therapists is a credential that can only be obtained through the The Hand Therapy Certification Commission at http://www.htcc.org/ So it should be possible for someone to validate that credential through that organization. In fact, assuming credentialing is in scope, when a given credential is associated with one and only one source, we should be linking to that source, to facilitate the credentialing process. Eventually, those sources should have provider directories of their own, so that they can automate the credentialing process. But at least linking to them seems prudent. There are some credentials like 'MD' and 'DO' that are verified by specific schools attended... and can even be acquired internationally, so there is no "single source of truth" but it does seem like if there is a "single source of truth" we should list it, especially if we want them to have provider directories eventually. I want to propose 1 that we add all of the credentials that are "in the wild" in NPPES 2. that we add the fields "is_credential_single_sourced (true/false)" and "credential owner name" and "credential owner url" and "credential owner provider directory url" to this data structure. How, where and to whom do I make that proposal?

Brian Postlethwaite (Jun 16 2019 at 23:45):

You are 100% right there. And one of the areas that will need further profiling during the next stage of the VhDir guide with the US specific credential providers etc. I was wondering who would be the appropriate registrar of these things, ONC, HHS, CMS, HL7? (the credential providers, not the identifier/qualification values)
In Australia we've started doing that in the au-base IG.
So could be another alternative to put these in US-Core and link into the VhDir IG, as these values are going to be used outside the directory too.

Elkhan Yusubov (Jun 17 2019 at 21:26):

Is there any guide on how to create a sample FHIR Provider directory server?
There is a Connectathon Jan 2019 at WGM , but is there a guidance/tool on how to load IG and sample data to the FHIR Server?

Lloyd McKenzie (Jun 18 2019 at 02:36):

@Brian Postlethwaite

Fred Trotter (Jun 18 2019 at 04:35):

given that this is an international problem, and that we do need to support cases where healthcare providers are switching countries and given that HL7 is the only international body on your list, I suppose that it makes sense that HL7 should ultimately own the "master list".
In the short term tho.. I think we should be adding a "country_jurisdiction" to the fields I just suggested in order to create a two-level namespace. I expect that M.D. etc probably can be verified by a single source in many countries and so it makes sense to use an appropriate country code there, in addition to the other values. While this seems like overkill, I expect that the assertion that "this Dr obtained their MD in spain" is exactly the type of long term benifits that the provider directory should be able to support...

But I still do not know how I go about getting new columns and new rows added this file that is being used today. How do I get that done?

Lloyd McKenzie (Jun 18 2019 at 04:40):

HL7 doesn't own any list of provider information. We define standards for sharing information via registries. We don't maintain a provider registry of our own and (to my knowledge), have no intention of doing so.

Fred Trotter (Jun 18 2019 at 04:44):

Sorry to be unclear, but I was not talking about lists of providers (although there do appear to be lots of them in the OID registry, so I am unclear what you mean when you say there is no list of providers..). but I am instead discussing lists of provider credentials, which lives here: http://hl7.org/fhir/v2/0360/2.7/index.html

Brian Postlethwaite (Jun 18 2019 at 08:44):

And those are credential types...

Elkhan Yusubov (Jun 20 2019 at 17:54):

Is there a weekly or monthly meeting for a group that works on VhDir (Validated Healthcare Directory)?

Brian Postlethwaite (Jun 21 2019 at 03:40):

You can ask questions on it in the #VHDir - Validated Healthcare Directory stream, which is where some of the discussions go on.
The development side has mostly wrapped up with the closing publication steps almost done.
Patient Administration is the group that handles this, and we are having weekly calls Wed 3pm eastern US, and you're welcome to post questions to the VhDir channel, or the #patient administration WG channel ahead of the call for discussion, so that others can prepare for the questions.
https://confluence.hl7.org/display/PA/2019-06-26+Conference+Call+Agenda

Gail Kocher (Jul 17 2019 at 20:01):

@Fred and @Brian Postlethwaite the list Fred's link refers to is provider degrees, which generally lead to licensure. Additional certifications, e.g. the hand therapy certification noted earlier in the thread, is a different kind of credential and I would be careful not to lump actual educational degrees leading to licensure with other, non-degree certifications or certifications that are in addition to the degree or license. Depending on the type of certification, having one will not by itself enable an individual to practice without having a degree and license first.

Iryna Roy (Jan 26 2021 at 05:04):

Hello dear colleagues, same as a time at birth, this same question keeps coming back: Provider Directory. IHE mCSD/ILR, VHDir or Argonaut? What is the difference? Which one to use to build or is there anything to re-use/upgrade? I think I am missing something important here and hope for help from the collective experience, please.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Provider Directory · implementers

Stream: implementers

Topic: Provider Directory

Radu Craioveanu (Oct 14 2016 at 12:22):