Stream: implementers
Topic: Facility Site Identifiers
Fred Trotter (Jan 15 2021 at 04:08):
Recently, I was presented with an interesting assertion: There is no healthcare facility identifier that uniquely identifies a given facility location in the United States. Indeed, I am hard pressed to disagree.
Organizationa are allowed to have more than one Organization NPI numbers in NPPES. Recent changes to NPPES allow for a single Organizational NPI to support multiple addresses. Practically there are many different clinics and hospitals that have multiple different sites that use the same NPI for billing and see no reason to change this, instead using billing address to differentiate to payers their various sites of service.
Neither is Medicare CCN an appropriate 1-to-1 facility to facility address match. CCN represent the "contract number with CMS" and is frequently used between sites with very different locations.
I see that HL7 has an OID service here: www.hl7.org/OID which seems to allow FHIR/NPPES/whatever to be subsumed underneath it, but it does appear to also be issuing unique OIDs to identify specific hospitals facilities too, but I see no indication that this even attempt to uniquely identify facilities by location.
I understand that FHIR URLs might be used in practitioner/facility identifiers data fields in what might previously have been only the domain of OID identifiers in the future (am I right? I have no idea). What is the closest thing we have to a unique identifier today?
If none exists, what is the most expedient way to make one that is compatible generally with FHIR including the provider directory efforts?
You were all so helpful the last time I asked about credentialling data, which is, like this question, adjacent to alot of the interoperability standards, I had hoped that someone might know more and be able to help my obviously amatuerish understanding of this issue.
Thanks,
-Fred Trotter
Lloyd McKenzie (Jan 15 2021 at 05:46):
@Larry Decelles
Larry Decelles (Jan 15 2021 at 13:20):
Hello @Carmela Couderc, are you able help out here? Larry
Fred Trotter (Jan 16 2021 at 15:25):
Any takers other than @Carmela Couderc ? Am working through a critical use case on this as we speak... need this answer quickly if at all possible.
Lloyd McKenzie (Jan 18 2021 at 22:51):
@Brian Postlethwaite was there any discussion of this in PA?
Brian Postlethwaite (Jan 19 2021 at 10:43):
This is a jurisdictional issue. Identifier systems are really about where they are allocated and maintained.
HL7 isn't going to try doing this.
Sorry that's not of much use.
@Saul Kravitz is this something that pdex covered? @Alex Kontur?
Gail Kocher (Jan 21 2021 at 19:42):
@Brian Postlethwaite I think @Saul Kravitz would agree with me in saying that Plan Net has the functionality in the Plan-Net Location for an identifier that belongs to the location if one exists. Plan-Net is not going to define or create a unique identifier for a location. Health Plans in most instances do not recognize (enroll, contract, credential) the location, i.e. the address, absent any information about the provider and therefore the location does not stand alone. Providers may enumerate within their systems their locations but such enumeration would not normally be information they need to share outside their own internal systems.
Fred Trotter (Feb 01 2021 at 08:23):
Hey, I appreciate these answers, but I still not know a definitive answer to the two parts of the question:
What does it mean to FHIR that HL7 is an OID provider? Will that ever matter?
Is there a facility-level identifier that FHIR is ever going to leverage?
Thanks,
-FT
René Spronk (Feb 01 2021 at 08:24):
As for the first question: no.
René Spronk (Feb 01 2021 at 08:25):
As for the second: FHIR core is never going to mandate nor specify the use of any particular identification mechanism. A specific FHIR implementation guide could either mandate the use of some existing identification mechanism, or it could define its own.
Fred Trotter (Feb 01 2021 at 08:28):
I see thanks for the answers.. this feels like progress and I appreciate it.
Am I correct in interpreting to answer that "facility level differentiation" is not a priority for the current FHIR implementers? That seems like the right interpretation, unless there some identification rubric that solves this problem that is becoming standard... I would imagine that ppl are just using NPI or CCN, which are not facility location specific.
-FT
René Spronk (Feb 01 2021 at 08:40):
Hi Fred - that level of detail is beyond me (too US specific for my mainly European background) - you may wish to follow up on the #united states stream, or with those that author the US Core IG specification.
Lloyd McKenzie (Feb 01 2021 at 16:18):
It's not true that FHIR core is never going to mandate nor specify the use of any particular identification mechanism. FHIR does mandate the use of specific URIs for a number of code systems and identifier systems. And there are change requests asking to define 'official' URIs for new code systems and identifier systems on a regular basis. The intention is that these will move to be managed on terminology.hl7.org and there's additional process coming into play, but that work will continue. Implementations that don't translate to the 'approved' URI are non-conformant.
How we handle U.S.-specific identifiers is really the question here. We don't have a good process set up for that yet.
René Spronk (Feb 02 2021 at 07:48):
Maybe the US-realm should step up to the plate - affiliates typically have a role to play in such an effort.
Lloyd McKenzie (Feb 02 2021 at 14:39):
@Eric Haas @Brett Marquard :)
Brett Marquard (Feb 02 2021 at 14:50):
given facility location
I am not aware of any such US government provided scheme -- during US Core ballot review, we had a conversation with a vendor that didn't assign location identifiers, so we shouldn't be requiring them.
Brett Marquard (Feb 02 2021 at 14:51):
@Fred Trotter what use case are you trying to solve?
Lloyd McKenzie (Feb 02 2021 at 14:51):
This probably wouldn't be provided by US government - this would be a function provided by US realm
Brett Marquard (Feb 02 2021 at 14:52):
US Realm assigning identifiers to locations?
Lloyd McKenzie (Feb 02 2021 at 14:53):
Implementers need an authoritative body (e.g. HL7) to definitively declare "The URI that is used for Michigan Physician License number is xxx" (and do the same for Florida Dental License Number, California Podiatry License Number, etc.)
Lloyd McKenzie (Feb 02 2021 at 14:54):
HL7 does this for certain international identifiers - and can do it for more. We also do it for a bunch of US and international code systems. However, there's been no energy put into US identifiers yet. And it's a need that desperately needs to be satisfied.
Lloyd McKenzie (Feb 02 2021 at 14:55):
All told, you're probably looking at somewhere in the range of 500-1000 different identifier types. Key thing to do is define the process.
Lloyd McKenzie (Feb 02 2021 at 14:56):
Not locations, "common public identifier types". So not identifiers created by hospitals or clinics, but identifiers created by licensing bodies or other oversight organizations (e.g. FDA) that are commonly captured across systems.
Brett Marquard (Feb 02 2021 at 14:58):
Would be great to have Fred come to US Realm to make sure the problem statement is clear -- I definitely see a role in HL7 helping declare the URI, but below that URI (i.e. identifier assignment + management) I think it's outside.
Lloyd McKenzie (Feb 02 2021 at 15:04):
These could be for providers, organizations or locations, though providers would be the most common
Lloyd McKenzie (Feb 02 2021 at 15:05):
Certainly no need for HL7 to manage the license numbers. Just saying "This is the URI you use for this identifier type".
Lloyd McKenzie (Feb 02 2021 at 15:05):
The only thing we might be asked to do is update the NamingSystem description to include a URL that points to the relevant agency's current website related to that identifier as it changes from time to time.
Brett Marquard (Feb 02 2021 at 15:52):
My gut is the problem isn't lack of HL7 URIs, it's lack of general management on identifiers...but I would love to be wrong.
Lloyd McKenzie (Feb 02 2021 at 16:55):
There's definitely a lack of URIs - to my knowledge, HL7 doesn't have NamingSystems for any US provider or facility license numbers. Management of the identifiers themselves is of course up to the licensing organizations. The only tricky bit for HL7 is figuring out when an identifier namespace covers multiple license types. E.g. it's possible that in some state, the same body licenses both physicians and dentists or RNs and LPNs - we'd need to know whether that's a single NamingSystem or multiple in order to properly assign URIs.
Eric Haas (Feb 02 2021 at 17:29):
I think what Brett is saying creating a list of ' 500-1000 different identifier types" is not the issue. The issue is the maintenance of it longterm Additions, updates, deletes, etc. this needs policies and possibly even its own registry. For example, we could be faced with Issues we are seeing now with code system urls we (hl7) created on the fly that now years later need to be changed ( e.g. California decides they don't like the hl7 assigned url and want it changed to what they want). I personally think that its something useful and should be federally hosted.
Lloyd McKenzie (Feb 02 2021 at 19:24):
California shouldn't have the authority to change what URL gets used in FHIR exchanges. They might be consulted in the initial selection, but once established, the URL can't be one that can be changed. (I'd strongly recommend a policy that says that all such naming systems will use a URI that's an HL7-assigned SID. That way we can ensure it resolves and update the metadata from time to time, while ensuring that the URI remains unchanged. Changing URIs once they're in broad use creates immense interoperability issues and costs.
Lloyd McKenzie (Feb 02 2021 at 19:25):
HL7 already has terminology.hl7.org which is fully capable of handling the maintenance side and tx.fhir.org which serves as an authoritative computable registry. While you could try to get the feds to set something else up, I'm not sure that it'd be worth it. And I'm also not sure that you'd get the consistency needed to properly support interoperability.
Last updated: Apr 12 2022 at 19:14 UTC
