Direct Address Storage in NPPES

[Alan Viars]

There has been some recent discussion on the best way to store Direct Addresses in NPPES. I have created the following document to facilitate the discussion.

https://github.com/HHSIDEAlab/pjson/blob/master/direct.md


Does anyone have any input on this topic?  Do you have a favorite option?

Alan

[Loran Cook]

For Options 2 and 3, I assume organization_npi_1 is always provided - is this correct?

[Darrell DeVeaux]

FYI, Doesnt' look like those of us outside HHS can access this link. It's requiring an Outlook login.

[Loran Cook]

Did the same for me trying to click through Outlook. Try copying and pasting the url directly into your browser. Worked on Firefox for me.

[Alan Viars]

Sorry I fixed the link.

Alan

On Thursday, December 4, 2014 9:23:39 AM UTC-5, Darrell DeVeaux wrote:

[Alan Viars]

Just fixed.

[Alan Viars]

The issue that has been discussed the most is around codification of the organization.

By  "organization_npi_2", I mean to convey a type II, NPI, only an organization. 

Perhaps assuming every provider Direct address will be associated with an organization is a faulty assumption?

When available, having an organization identifier alongside each address would help keep straight when Dr. Smith is has multiple addresses because she or he provides services through two organizations.

-Alan

[Alan Viars]

https://github.com/HHSIDEAlab/pjson/blob/master/direct.md

On Thursday, December 4, 2014 9:27:45 AM UTC-5, Loran Cook wrote:

[Loran Cook]

Okay, I think I follow. In order for Option #2 to work, though, organization names must be unique, so that if no organization_npi_2 is provided, the organization name can be matched to a valid/active NPI, correct?  Without even looking at name_former and name_dba, the strict organization business name where entity_type=2 in the current file (2014-11-14) has over 72k names of organizations that are used for more than one active NPI.

My 2 cents (if I understand your dilemma correctly): have another Boolean for is_business, like is_public, then prompt for a second organizational NPI. If that is a usability issue (to require a business NPI that the user may not know), have another prompt where organization name is accepted, queried for active NPIs and the user is prompted to choose from several NPIs, giving name, address, taxonomy, etc. to help prompt the correct identifier choice.

[fred trotter]

Alan,

The current github is proposal is somewhat confusing because it
sometimes suggests organization_npi_2 and other times
organization_npi_1

The meaning of the _2 and/or _1 is confusing. It should just be
"organization_npi" or even better "hisp_organization_npi".

First, I would not introduce any freetext name fields, all this does
is create the opportunity for fat-fingering and general chaos. What
would it mean, for instance, if you had an npi that mapped to an
organization with the name "Great Hospitals Inc." but the name in the
name field is set to "OK Hospitals Inc." Having the name there means
that you would have to either disassociate the name of the
organization in the provider file, from the name in the organizational
file, OR you would need to auto-update the organization name from the
organization record. That would mean that if "Great Hospitals, Inc."
changed its name to "Really Great Hospitals, Inc." you would need to
update the thousands of provider records that had that organizational
NPI as their Direct provider. Neither approach one works, which is
really just the case for normalization in general.

So there is no reason to have the name field at all, if you have the
npi, you can do a lookup on the organization name, it can change
independently.

This gets you out of the problem that Loran is correctly points out,
sometimes organizations have hundreds of NPI records for their
different locations.

It should be noted that this would have the side-effect of forcing
third party Direct address providers (HISPs) to register for an NPI. I
think this is a good idea, but one might argue that the DNS system
alone should be used to identify Direct end points, rather than
forcing all HISPs to have an NPI.

I think it is a fine idea, because the rules for organizational NPIs
is so loose. An individual, by policy, (and possibly law... not sure)
cannot have more than one individual NPI. But an organization can and
do have many NPIs and they have the right to create NPI for their
sub-parts. That means that Surescripts (for instance) can create an
distinct NPI for "Surescripts Direct HISP" in order to make it
distinct from any other NPI it might have.

If you are going to go down this path, however, you should do it
right, and enforce a many to one rule for domain end points to
organizational records. So if someone registers
"fr...@direct.greathospitals.com" and points it to NPI 1112223334 then
someone else registers "al...@direct.greathospitals.com" and points
that record to an organizational NPI of 9998887776 then the system
should say refuse to make that update.

Of course registering "al...@direct.reallygreathospitals.com" and
pointing it to 1112223334 would not be a problem at all. The complete
rule would be one organizational NPI can own many direct domain names,
but a direct domain name can only be owned by one organizational NPI.

This would cause a little user friction in the beginning as people got
frustrated that users incorrectly chose the organizational NPI for
their direct provider, but long term it would ensure that the overall
architecture of the system was very very clean. People would have to
decide what organizational NPI to use for this purpose, likely
creating one specifically for this, and then stick to it long term.
This would automatically create a clean registry of HISPs as a side
effect.

Thoughts?

-FT

> --
> You received this message because you are subscribed to the Google Groups
> "NPPES Modernization Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nppes+un...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Fred Trotter
Blog: http://radar.oreilly.com/fredt
Twitter: https://twitter.com/fredtrotter

P.S. I do Open Source healthcare software. Because I frequently give
code/data away for free, I get lots and lots of email, expecting more
free stuff. So much so that I now have trouble keeping up with email.
If you are or plan on paying me, and you are having trouble getting
ahold of me, please contact Ashish Patel. If not, please expect that I
might take between 30 and 90 days to get back to you. I will also
probably not read emails where I am merely cced. Its not personal. I
just cannot spend 8 hours everyday emailing. I still love you all.
Really. -FT

[fred trotter]

Also, I am completely against is_public.

Direct has both side certificates. It is inherently spam proof, there
is no reason to not have a Direct address public.

Moreover, if a direct address is not fit for public consumption then
it is not clear why it would be listed in NPPES.

If you put this field in there, and expose a corresponding GUI, you
are going to be setting up false expectations with the end users no
matter how you slice it.

-FT

[Alan Viars]

Fred:

Replies in line below.

On Thursday, December 4, 2014 10:33:28 AM UTC-5, fred trotter wrote:

Alan,

     The current github is proposal is somewhat confusing because it
sometimes suggests organization_npi_2 and other times
organization_npi_1

The meaning of the _2 and/or _1 is confusing. It should just be
"organization_npi" or even better "hisp_organization_npi".

Yes it was broken and confusing.  Its all_2 now.  I think I like "organization_npi".


 

First, I would not introduce any freetext name fields, all this does
is create the opportunity for fat-fingering and general chaos. What
would it mean, for instance, if you had an npi that mapped to an
organization with the name "Great Hospitals Inc." but the name in the
name field is set to "OK Hospitals Inc." Having the name there means
that you would have to either disassociate the name of the
organization in the provider file, from the name in the organizational
file, OR you would need to auto-update the organization name from the
organization record. That would mean that if "Great Hospitals, Inc."
changed its name to "Really Great Hospitals, Inc." you would need to
update the thousands of provider records that had that organizational
NPI as their Direct provider. Neither approach one works, which is
really just the case for normalization in general.

So there is no reason to have the name field at all, if you have the
npi, you can do a lookup on the organization name, it can change
independently.

Good point.

 

This gets you out of the problem that Loran is correctly points out,
sometimes organizations have hundreds of NPI records for their
different locations.

It should be noted that this would have the side-effect of forcing
third party Direct address providers (HISPs) to register for an NPI. I
think this is a good idea, but one might argue that the DNS system
alone should be used to identify Direct end points, rather than
forcing all HISPs to have an NPI.

I think it is a fine idea, because the rules for organizational NPIs
is so loose. An individual, by policy, (and possibly law... not sure)
cannot have more than one individual NPI. But an organization can and
do have many NPIs and they have the right to create NPI for their
sub-parts. That means that Surescripts (for instance) can create an
distinct NPI for "Surescripts Direct HISP" in order to make it
distinct from any other NPI it might have.

If you are going to go down this path, however, you should do it
right, and enforce a many to one rule for domain end points to
organizational records. So if someone registers
"fr...@direct.greathospitals.com" and points it to NPI 1112223334 then
someone else registers "al...@direct.greathospitals.com" and points
that record to an organizational NPI of 9998887776 then the system
should say refuse to make that update.

Of course registering "alan@direct.reallygreathospitals.com" and

pointing it to 1112223334 would not be a problem at all. The complete
rule would be one organizational NPI can own many direct domain names,
but a direct domain name can only be owned by one organizational NPI.

What happens when the domain changes?  Should the NPI-2 (Organizational NPI) record list its Direct domains?
 

This would cause a little user friction in the beginning as people got
frustrated that users incorrectly chose the organizational NPI for
their direct provider, but long term it would ensure that the overall
architecture of the system was very very clean. People would have to
decide what organizational NPI to use for this purpose, likely
creating one specifically for this, and then stick to it long term.
This would automatically create a clean registry of HISPs as a side
effect.

Yes this more strict approach would create the cleanest well/codified directory.

> email to nppes+unsubscribe@googlegroups.com.

[Alan Viars]

Hi Loran:

Yes I had some typos.  _1 should be _2.  This is now fixed.

So you are suggesting a user can enter any direct address, but when is_organization is provided the NPI-2 (Organizational NPI) must be provided in some way either by entering the NPI or via a name-based lookup??

Alan

[Alan Viars]

Fred:


I agree. If its not public don't register it right?

I'll suggest that change an internal meeting later this week.

I think that was added because we heard so many opinions on the matter.

Alan

> Of course registering "alan@direct.reallygreathospitals.com" and

>> email to nppes+unsubscribe@googlegroups.com.

[fred trotter]

I can live with just organizational_npi, without a name and without a
(_1 or _2)...

Could you add that as the "strictest" proposal on github, just to make
sure we are on the same page...

It might be a good idea to allow organizational NPI's to "claim"
Direct domain names, but only because that would reduce user friction
in the end... If you did that, then you could just say "I know what
NPI owns this domain name" when someone adds their address, rather
than asking them to enter a specific organizational NPI.

That would smooth things out and force users to coordinate with their
HISPs in a more reasonable fashion.

-FT

>> > Of course registering "al...@direct.reallygreathospitals.com" and

>> >> email to nppes+un...@googlegroups.com.

> --
> You received this message because you are subscribed to the Google Groups
> "NPPES Modernization Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to nppes+un...@googlegroups.com.

[fred trotter]

Of course, I still vote for having an actual "can I find and download
the cert for this direct address" as part of the error checking as
well.

[Loran Cook]

Yep! I'm definitely a fan of any changes that make it easier to understand how providers are connected.

[Alan Viars]

I have added options 4 and 5 based on this thread. Option 3 is strict, option 4 is more strict and option 5 is most strict.
I think the #4 basicly describes what Loran suggests and #5 is what you suggest.

Thought comments?
Alan

>>> > Of course registering "alan@direct.reallygreathospitals.com" and

>>> >> email to nppes+unsubscribe@googlegroups.com.

>> email to nppes+unsubscribe@googlegroups.com.

[Alan Viars]

Hi Loran:

I added options 4 and 5 based on our thread.  Thoughts?

Alan

[Loran Cook]

I think #5 could work with some interface help on finding NPI-2 if the user doesn't automatically know it. I know I don't walk around with my employer's TIN memorized....but, I'm not a healthcare provider. Everyone knows *they* are supposed to be perfect. Please excuse the snark - it is Friday, after all. :)

[Hack G]

I agree mostly with Fred and prefer 4 or 5. Under no circumstance would I open a text field for a user to type their organization name and leave it at that! This is precisely the type of dirty data we wish to see prevented in the future (and are very fortunate for all your work and keeping us involved Alan). If the NPI can be entered then it should import the organization name from the org's record


And Loran makes a great point if the NPI is not known but the org's name is - this is the one exception to the open text field featuring some version of a type-ahead (JS)

another prompt where organization name is accepted, queried for active NPIs and the user is prompted to choose from several NPIs, giving name, address, taxonomy, etc. to help prompt the correct identifier choice.

On Friday, December 5, 2014 10:50:02 AM UTC-5, Alan Viars wrote:

Hi Loran:

[Alan Viars]

Thanks for all the great feedback guys:
Based on this feedback and other feedback on "associations" in general, I have this new proposal.

https://github.com/HHSIDEAlab/pjson/blob/master/associations.md

Thoughts?

Alan

[Michael Wasser]

Alan,

Thanks for putting this all together -- looks like a lot of interesting content. In trying to catch up with the thread a bit, I'd be interested in hearing about how this relates to an actual implementation of collecting provider network data from payers. Who does this plan go to after it is reviewed here? Is there a timeline/ expected bodies that will need to be interfaced with? Is there some kind of summary documentation on your current effort beyond at a technical level just to get an idea of the potential impact of our input here?

At a technical level, this seems to assume JSON is preferable to other formats. I gather from other threads and the doc that hosting the JSON at URIs is preferred in your spec to flat files (is this assumption correct?). Personally, I think it might make sense to go the more traditional route first -- something like CSVs for all the different aspects of the data and then provider helpers like URIs and structured data (such as JSON) as an extra if possible. Must have would be the raw data, nice to have is interesting ways to interface with it. Could totally keep the same data structure, but I think theres a lot more flexibility in CSVs compared to JSON. In addition, CSVs would be much smaller + much faster to use.

Michael

[Alan Viars]

Hi Michael:

I don't have a high-level overview.  I've just attempted to take all of the requirements form various groups and distill it into a structured document format.  I've just introduced this idea to the folks that work with health plans at CMS so the described "associations" is really a paper tiger at the moment.

As far as JSON v/s CSV goes, its a "both and". CMS will continue to produce the CSV as it exists today, but uploading data to the API and reading data from the API is expected will be in the form of  a structured document.  That document format is JSON only at the moment, but could be represented as XML without too much fuss.

Also the "provider data tools" converts between CSV and JSON. Soon it will do the same in the other direction.

Hope that helps.  I'd like to bounce this around with you by phone.  Perhaps later this week?

Alan

[Alex]

Hi Alan,

I have been following this discussion for quite some time now. Congratulations for all the work you have done so far! The API has come a long way.

So my question evolves around the data and in particular about the email addresses. Is there an estimate of the percentage of providers having an email address in the modernized NPPES data? Or will it still carry the same email information of current NPPES, which is nonexistent by the way?

Finally, and perhaps that has already been answered, do the associations between an individual provider and an organization derive from the Physician Compare dataset of CMS (https://data.medicare.gov/data/physician-compare)?

Thanks,

Alex

[Alan Viars]

Hi Alex:

Glad you like the new API so far.

RE "email" address you are correct about email. There is an email for the "contact person", but that is usually not the provider.  There is also the email address associated with the login email for I&A (which I do not have access to).

In the new system, there is a an "email" and "website" fields within the "basic" dictionary object.   This is optional because CMS position is that nothing can be required except for that which is in the NPI final rule.

Mashing up NPPES and Physician compare would be interesting, but not something that would be not be done by CMS as far as I know.  However if we wanted to prepopulate suggestions and get confirmation using this information, that could be possible.

Have we done a phone-based stakeholder interview with you?


Alan