I've been playing around on the NPPES National Provider Identifier Registry to see how the webtool works, and get my first look at "real" NPI data. I was one of many who warned that the data itself -- nearly all of which was entered manually and without independent validation -- would be of questionable consistency. Some of those questions have been answered by my search sessions, and the answers don't look good.
I also worried about the capabilities of the tool itself -- not much was promised in the way of search functionalities by the CMS design team. They get an "A" for expectations management, at least. The search options are rudimentary at best. Actually, that's a little generous.
But before anybody completely discards the notion of value in the data or the search tool, I should express my optimism. The search can be improved -- and as it turns out, I have some helpful suggestions. Likewise, the owners of the data can and should -- and will -- be encouraged to clean it up. Read on for a click-by-click account, with color commentary.
Write About What You Know
The best way to test anything is by starting with a known commodity. I worked at St. John Health System for about 13 years, so I thought I'd start there. The resulting screen offered five search fields: NPI, Organization Name, Practice Address City, Practice Address State, and Practice Address Zip.
Listing "NPI" as a search parameter might seem sort of, how can I put this? Tautological? I mean, I'm here because I've been waiting for over three years to be able to look up an NPI, not because I've been accumulating nameless numbers I now want to decode. I remind myself that this is a tool for the ages, not just for assuaging my pent up NPI separation anxiety. Certainly in the years ahead, people will be finding 10-digit numbers lying around that they simply must be able to resolve into provider names, rather than the other way around.
Practice Makes Prefect?
But it's that repeated label "Practice Location" that really gives me pause. "Practice?" Type 2 (organizational) NPIs are assigned to hospitals, clinics, labs, nursing homes, emergency rooms, etc., etc. None of these facilities are referred to as "practices" by anyone experienced in healthcare. The use of such imprecise labels -- perhaps an effort to distinguish them from the "mailing address" fields? -- suggests either a lack of domain expertise or a lack of concern about logical precision.
Maybe I'm just being picayune, but after a couple of decades of reviewing software products and participating on design teams, I don't overlook the subtle implications of such first impressions. Sloppiness on the front end is generally not inversely proportional to back-end integrity.
Getting On With IT
There is some helpful documentation on the page:
Please enter data for at least one of the following fields. If searching on Practice Address State, you must enter data for at least one other field. To perform a wild card search, at least two characters must be entered before the "*". For example, to search for data beginning with "Ch", enter "Ch*". Wild card searches are only available on the Organization Name and Practice Address City fields.
Okay, so if I want to see how many different NPIs my old friends at St. John obtained, I could start by entering a partial name, then city and state. I entered these (all strings copied/pasted from search sessions -- I am not going to be guilty of transcription errors!):
St. John*
Tulsa
OKLAHOMA (selected from dropdown)
This results in 11 hits. The columns are listed as NPI, Organization Name, Street, City, State, Zip, Primary Taxonomy, with an additional column offering a link labelled "Details" for each row.
SPAM Egg Sausage and SPAM
The names in the first four rows are distinct: St. John Anesthesia Services, Inc., St. John Dialysis, Llc, St. John Emergency Services, Inc. and St. John Kidney Dialysis, Llc. The irregular capitalization sets off my sloppiness sensor, but I grit my teeth and keep scanning. The next 6 rows share a common name: "St. John Medical Center," and the same street address, which sends me over to the Primary Taxonomy column for the tiebreakers. The entries in that column for the six rows are "Hospital Units, Nursing & Custodial Care Facilities, Agencies, Hospital Units, Agencies and Hospitals," respectively.
Hospital Units and Hospital Units? Agencies and Agencies? I had to dig deeper, so I clicked on the Details link for the rows that looked exactly the same. The first "Hospital Units" row resolved to a taxonomy code of "273Y00000X - Rehabilitation Unit;" the second "Hospital Units" record was "273R00000X - Psychiatric Unit".
Department of Redundancy Dept.
Likewise the two "Agencies" were differentiated as "251G00000X - Hospice Care, Community Based" and "251E00000X - Home Health".
So I guess by "Primary Taxonomy" they don't mean the actual taxonomy code designated by the provider on the application, but the higher-order "Level I" taxonomy, which only has a descripition, without a corresponding 10-character code. And the advantage to listing this uncoded, more ambiguous generality in place of the specific code and corresponding description that could precisely distinguish between those two "Hospital Units" or that pair of "Agencies" would be....?
Brevity Is the Soul of Witlessness
Okay, so being less specific takes up less space on the screen. But when somebody is coming to NPPES, they are looking for what makes the records unique, not what makes them fit on a single row of text. If the developers implemented a multi-row format for the search results, then differentiators like "Other Name" and "Other Provider Identifier" could be added (in addition to the user-designated Taxonomy code replacing the higher-order description) to make it a lot easier to determine the correct entity/subpart. Otherwise you may need to drill into several results and do a window-by-window compare.
Sts Be Praised!
So, so my old friends at St. John chose to obtain 11 NPI's, eh? Wow. But wait.... Eliminating the period from my search string (the Organization Name on the query now reads "St John*") turns up 6 more entities.
What's a bit more troubling is that St John Cardiovascular Medicine, Inc is listed at a Street address of "E st St". I know my hometown pretty well, and there is no st Street in Tulsa (the county historical society confirmed that an early city planner had a horrible stutter, but they didn't let him draw the maps).
Could the provider have mistyped it? Nope. Drilling into the record shows that both the Business and Mailing Addresses are listed as "1923 E 21st St 200". That may still be a little malformed (I'm guessing the postal service would prefer the normalized variant, "1923 E 21 ST STE 200", but I won't quibble over such matters at this point).
Garbage In, Garbage Out, Garbage A La Carte
The implication here, though, is that the query must be pulling out something other than the provider-supplied address. Okay, so the real-time query thing, that was sort of an embellishment, right?
Next row offers up another fatfinger: "St John Cardiovasuclar Services, Ind". Ind? Is that like Gary, Ind?And what are Cardiovasuclar services? Is that simular to Nucular medicine?
I'm not making (just) fun -- I'm making a point. If you look at the two records, they appear nearly identical -- only the addresses are different, and the names are nearly the same. So you better make sure you spell those names correctly.
And what about those dots? Should somebody tell all them Johnnies that they ought to decide whether they are St. John or St John?
Zwei, Drie, Vier, Funf....
Another critical cross reference -- the EIN or Employer Identification Number -- is "temporarily suppressed," according to the Detail display. The text at the top explains, "an incorporated individual may have reported an SSN as the EIN of the corporation. To protect the privacy of this individual, we have temporarily suppressed the EIN...."
Hmmm. I'm kind of absent-minded, and sometimes when a form asks for my birthdate, I write in today's date -- but that doesn't mean I expect people to treat me like an infant.
Not having the EIN disables a critical capability: Determining how many subparts a particular entity has chosen to enumerate. This doesn't just make it easier to match; it ensures you haven't missed one. For instance, there may be an entity that doesn't start with the same name/prefix, but is a part of the same corporation.
It's Time to Put On Your Thinking Caps
I know that there are some corporate entities under the St John umbrella that don't start with St John (or St. John, for that matter). How can I find them?
My search parameters don't give me a lot of options. I try City, State and ZIP, using the zip code 74104, in which the main campus resides. After all, how many Type 2 providers could there be in one zip?
That Does Not Compute
I get a pretty quick answer: "More than 150 records were found matching your search criteria. Please refine your search criteria to return fewer results." But the only refinement they offer is the name, which is the thing I've moved to the "unknown" category in my thought process. And I don't know the NPI, which is the only other search field.
I realize that St John typically employs the same street address for its on-campus corporate entities, and lets its own mail room sift through the resulting heaps of letters and packages. So I scan down through the street addresses looking for 1923 S Utica Ave. (If I could search for a street name, by the way, I could greatly increase the chances of a hit and reduce the likelihood I would exceed the 150 max.)
The results are not pretty. These are direct copy/pastes from the NPPES results screens: "1265 S Utica Avesuite 102", "1265 S Utica Avesuite 300", "1145 S Utica Aveste 800", "1826 E 15th Stsuite A", "E Street" (what is that about? Asbury Park Pediatrics?), "E th St" (near the corner of st St?), "2000 S Wheeling Avesuite 300", "E th Stsuite ", and "1145 S Utica Avesuite 362". That's nine malformed addresses on the first 20 rows of results. Ouch.
Maybe a poorly displayed result set is not as bad as the typographical errors that are part of the native provider record, but a glitch that results in an error rate of 45% on a single column is more than unacceptable, it's embarassing. They gave themselves an extra three months to get this right -- purportedly for privacy concerns, not technical challenges. Didn't anybody look at this thing?
We're Sending You Back to Primary (Taxonomy) School
Next page brings some more bad news -- "Board Of Regents Of The University Of Oklahoma Ou Physicians Tulsa," which lists an address of "Kendall Whittier Elementary School2601 E 5th Place" says it has "No Primary Taxonomy."
I beg your pardon? I thought applicants had to list a valid medical taxonomy to obtain an NPI....
Well, drilling in as we must, it seems that this school-based provider does have a taxonomy. In fact, it has two pairs of taxonomies, each of which has been designated as a Primary Taxonomy in the display: "193200000X Multi-Specialty Group and 208000000X - Pediatrics" as well as "193200000X Multi-Specialty Group and 2080P0006X - Pediatrics - Developmental - Behavioral Pediatrics". We're hoping this is a temporary artifact of the late addition of a "primary" designation when multiple taxonomies are selected by the provider. Regardless, they don't office at 1923 S Utica, so we ignore them. Sorry, kids.
Declare the Pennies On Your Eyes
I still don't trust the "Primary Taxonomy" approach: I suspect CMS wanted to provide a crutch for all the systems that still don't understand that providers can and will have multiple taxonomies, any of which need to be seen as a "match" by providers and payers alike. Arbitrarily designating a "primary" taxonomy (or worse, rolling up a very specific coded taxonomy to a mealy-mouthed description-only "Level I," like they do on the search results display) will be an ineffective way to forestall the inevitable: If you're going to use Taxonomy, you need to design your system to understand it; if not, you are likely to force your trading partners into slapdash accommodations to your technical inadequacies.
Okay, on the following page, we come up with some familiar corporate names: "Utica Services Inc." (listed twice, both times taxonomized as "Ambulatory Health Care Facilities"), "Pathology Laboratory Associates, Inc.," "Clinical Partners Pllc Oklahoma" (okay, that one's not so familiar, but it sounds like it could be a new one), "Regional Medical Laboratory, Inc" (those guys are great -- real sharp in IT, and good to work with to boot).
Now we're up to page 6. "Continuous Care Center" (technically, their address is listed as "1923 S Utica Ave4 South" but I'll give them a pass). None on page 7 and page 8 is truncated at 10 rows. So the score is 11 Sts, 6 St.s and 6 uncanonized candidates. But we don't know whether more 1923 S Utica addresses fell out of the first 150 results, and we don't know whether there were other corporate entities that didn't use that common mailing drop. (In fact, I happen to know that some of the Wheeling addresses are St John entities, but we're trying to keep this simple, right?).
Seven Score and Ten
150 results is all you get, and for Tulsa that's not nearly enough to do what I was trying to do. Why? Because St. John is a big hospital, and the doctors, clinics and pharmacies cluster around it like chicks around a mother hen. Not only that, the geography of healthcare being what it is, another hospital is located on the same street a mile away -- in the same zip code. Tulsa's not a small town -- it's bigger than St. Louis, Cincinnati or Minneapolis (if you don't count St. Paul!). But it's no metroplex. There are close to 50 cities as big or bigger. 150 isn't enough results -- or, more to the point, name and address aren't enough search fields to consistently produce fewer than 150 results.
We will need that EIN to be a search field, when CMS decides to make it available. Other Provider Identifier would be a good one, too, since that's the first crosswalk that people will be looking for.
Do all of those entities belong to "St. John?" Certainly not. I know they use more than one corporate EIN, for one thing, and some of these affiliates are for-profit entities, which casts a further cloud over the "relatedness" of one to another. But if I'm a payer or trading partner that has a dozen or two different records I think of when I think of "St. John," I want to make sure I have matched them all up, and I want to make sure I haven't missed any. I can't possibly do this with the NPPES query the way it is configured now, nor with the data, with all the user-introduced (but user-fixable!) errors that are in it.
Wait Here and Guard My Optimism
There will be better query capabilities. I hope that CMS makes a few improvements, and I know that some private entities will be massaging the data and making it more accessible. Heck, we've even talked about doing some of that here at HITTG.
Why not? We're the number one site for intelligence on NPI -- we ought to be the number one site for NPI stupidity. Wait, cancel that thought.....
We'll also see the quality of the data improve, if only because people will be pointing out the errors it contains to the people who own the records. Providers have control over the data, and they have a vested interest in its accuracy. This is in contrast to the notoriously defective UPIN registry, which did not support direct data entry and suffered from a tradition of neglect by those charged with maintaining it. CMS issued the numbers, then relied on internal, inaccessible records from that point forward.
Finally I gave up using it and went back to the trusted and well-functioning NPI Lookup.
No comments:
Post a Comment