Closed jmandel closed 4 years ago
I think you are right about this, it could go to 0..1 with an NPI slice. NPI is organization, not necessarily location specific.
The question though is why refer to Organizations by FHIR Identifier (NPI slice, in reference.identifier) instead of by FHIR id (in reference.reference)? The latter always lets a data provider pass along an NPI (e.g. in a contained Organization), without limiting you to just an NPI.
Nitpicking: reference.reference
Uhm, nitpicking back... @michelemottini what's profiled is reference.identifier, using the reference by identity feature of R4.
And THAT, @jmandel , is why is why I started at NPI, b/c without having to dereference a FHIR Resource, you know the organization that is reporting on it.
NOTE: I profiled things tight to get just this kind of feedback though. Loose constraints are often ignored until someone LATER figures out that tighter would have been a better choice.
As an aggregator, you can/will know the NPIs of your BA's AND they won't collide, but you won't know all the FHIR ids they use to represent themselves, and id itself without endpoint the base URI might collide.
Thanks for the nit -- fixed @michelemottini
There also is a CCN by Medicare. Does every org with CCN also have an NPI?
This is likely Measure specific.
When I see the BedGroup defining a reference to an Organization at:
Why require reference.identifier, vs providing a reference to a FHIR resource that might contain not only an NPI, but other information too? For example, the information source sending Group data might also be sending Organization data, and could unambiguously refer to the correct Organization via reference.reference, rather than reference.identifier. (Imagine a scenario where the receiving system already had a bunch of data imported from different sources, and had multiple Organization resources all with a single NPI -- this gets messy). If only the NPI is known, we can always provide a contained resource (though I suspect that's not super common).
Or, backing way up: why do we need a managingEntity here at all? If we already have a Location (pointed to through the "Location.partOf" characteristic, that location can provide all the necessary geographical details, and if desired can point to an organization too.