As of July 10, the NPPES data file now contains substantially more data.
NPPES is a core data file for us at CareSet. NPPES stands for National Plan and Provider Enumeration System and is the dataset that helps us uniquely identify healthcare providers, using “National Provider Identifiers” or NPI numbers.
This dataset was created by the Clinton-era health reform efforts, and was made by a part of the HIPAA law that most people do not pay attention to. The first release of these numbers, in 2007, had two major impacts. For the healthcare system, it allowed for far smoother electronic medical billing. For data journalists and researchers (like us), it built the layer of abstraction needed for modeling the entire healthcare system. It’s hard to underestimate how critically important the NPI is in accurately quantifying the US healthcare system.
But NPPES has not been without its flaws. Most substantially, NPPES has been an anchor in healthcare interoperability efforts. NPPES is the only system by which CMS (and more generally, the Federal Government) provides verifiable contact information for a healthcare provider. And for years, NPPES has promoted fax numbers as the way to communicate healthcare data. As much as efforts to digitize healthcare records have advanced over the last decade, we have still not been able to shake the fax machine as the primary mechanism for transferring healthcare information.
And this month, the most substantial single improvement in the NPPES data has changed that.
The new NPPES file is made up of three files. All of them are very useful and important, but one of them is a game-changer. The three new files are:
- The Practice Location File – which allows a provider to detail more service locations
- The Other Name File – which allows organizations to publish additional names that they do business under; and
- The Endpoint File – which allows providers to publish digital health information exchange endpoints.
The Endpoint File is the beginning of the end for Fax machines and the beginning of the race between the several digital health information exchange protocols that are listed there. Specifically, the following endpoint types are supported.
I have helpfully labeled the three legitimate competing standards for health information exchange here. This will allow healthcare providers to publish their interoperability details, as opposed to simply fax numbers.
It will also allow them to publish websites, including the web addresses of their PHR records, which will allow for better patient to provider communication.
Of course, I remain somewhat biased in favor of the Direct Protocol (I spent a lot of time helping design the security architecture on that project) but all of the data transfer mechanisms listed here, including plain-text email are superior to Fax for health information exchange. Plain text email has no security advantage, but it can at least transfer digital EHR records, instead of “dropping to paper”.
This is the starting pistol for a race. Which protocol will win? So far, here is how the numbers break out!
We found more than 4 thousand distinct domain names in the endpoint dataset!
Of course, there are some “starting out” issues with the data. It is painfully obvious that CMS did not check the validity of the endpoints involved. Hopefully, in future releases, CMS will take the steps that it needs to in order to ensure that the endpoints are valid records!
Here are the various errors in the file
- The NPI 1669778122 had a row of blank values.. with no data anywhere.
- Lots of times the actual endpoint is blank, or just a space.
- There are many cases where an email address is labeled as a WEB field.
- There are many cases where an email address is labeled as a direct address… hotmail does not provide a DIRECT service.
- There are many cases where a domain name, like ‘example.com’ is an a URL field… should be something like ‘http://example.com’ etc., etc.
- There are many cases where the file content is gibberish, here is a quick sample:
- ‘HIPPA and Health IT’
- Sometimes, physical addresses were used for records, especially in the “OTHERS” type.
- There are many cases where CONNECT addresses are just plain web addresses, I expect this is true for FHIR too, but I think the word “connect” is being mis-understood
I expect that all of these issues will be fixed in due time, and this file will become one of the most valuable files that CMS releases. This could have as much of an impact on interoperability as the entire Meaningful Use paradigm did.
Congratulations to the team at CMS that made this happen!!