Thursday, September 13, 2007

NDC Numbers

What are the NDC Number and the National Drug Code Directory?

The Drug Listing Act of 1972 requires registered drug establishments to provide the Food and Drug Administration (FDA) with a current list of all drugs manufactured, prepared, propagated, compounded, or processed by it for commercial distribution. (See Section 510 of the Federal Food, Drug, and Cosmetic Act (Act) (21 U.S.C. § 360)). Drug products are identified and reported using a unique, three-segment number, called the National Drug Code (NDC), which is a universal product identifier for human drugs. FDA inputs the full NDC number and the information submitted as part of the listing process into a database known as the Drug Registration and Listing System (DRLS). Several times a year, FDA extracts some of the information from the DRLS data base (currently, properly listed marketed prescription drug products and insulin) and publishes that information in the NDC Directory.

The information submitted as part of the listing process, the NDC number, DRLS, and the NDC Directory are used in the implementation and enforcement of the Act.

According to Wikipedia, National Drug Code (NDC) is a unique 10-digit, 3-segment number assigned to each medication listed under Section 510 of the U.S. Federal Food, Drug, and Cosmetic Act. The number identifies the labeler or vendor, product, and trade package size.

  • The first segment, the labeler code, is assigned by the Food and Drug Administration (FDA). A labeler is any firm that manufactures, repacks or distributes a drug product.
  • The second segment, the product code, identifies a specific strength, dosage form, and formulation for a particular firm.
  • The third segment, the package code identifies package sizes.

Both the product and package codes are assigned by the firm.

The NDC will be in one of the following configurations: 4-4-2, 5-3-2, or 5-4-1.

Each item is barcoded with a Universal Product Code that begins with a 3 (UPC-A) or 03 (EAN-13). The remainder of the numbers are the NDC number, plus the check digit.

An asterisk may appear in either a product code or a package code. It simply acts as a place holder and indicates the configuration of the NDC. Since the NDC is limited to 10 digits, a firm with a 5 digit labeler code must choose between a 3 digit product code and 2 digit package code, or a 4 digit product code and 1 digit package code.

Thus, you have either a 5-4-1 or a 5-3-2 configuration for the three segments of the NDC. Because of a conflict with the HIPAA standard of an 11 digit NDC, many programs will pad the product code or package code segments of the NDC with a leading zero instead of the asterisk. For consistency, other Government agencies may display the NDC in an eleven digit format. For example, the Centers for Medicare and Medicaid Services (CMS) displays the labeler code as 5 digits with leading zeros; the product code as 4 digits with leading zeros; the package size as 2 characters with leading zeros.

Since a zero can be a valid digit in the NDC, this can lead to confusion when trying to reconstitute the NDC back to its FDA standard. Example: 12345-0678-09 (11 digits) could be 12345-678-09 or 12345-0678-9 depending on the firm's configuration. By storing the segments as character data and using the * as place holders we eliminate the confusion. In the example, FDA stores the segments as 12345-*678-09 for a 5-3-2 configuration or 12345-0678-*9 for a 5-4-1 configuration.

What products are included in the NDC Directory?

The current edition of the NDC Directory is limited to prescription drugs and insulin products that have been manufactured, prepared, propagated, compounded, or processed by registered establishments for commercial distribution. The products have been listed in accordance with the Drug Listing Act and regulatory provisions concerning the submission of drug product information to FDA.

Each listed drug product listed is assigned a unique 10-digit, 3-segment number. This number, known as the NDC, identifies the labeler, product, and trade package size. The first segment, the labeler code, is assigned by the FDA. A labeler is any firm that manufactures (including repackers or relabelers), or distributes (under its own name) the drug. The second segment, the product code, identifies a specific strength, dosage form, and formulation for a particular firm. The third segment, the package code, identifies package sizes and types. Both the product and package codes are assigned by the firm. The NDC will be in one of the following configurations: 4-4-2, 5-3-2, or 5-4-1.

An asterisk may appear in either a product code or a package code. It simply acts as a place holder and indicates the configuration of the NDC. Since the NDC is limited to 10 digits, a firm with a 5 digit labeler code must choose between a 3 digit product code and 2 digit package code, or a 4 digit product code and 1 digit package code.

Thus, you have either a 5-4-1 or a 5-3-2 configuration for the three segments of the NDC. Because of a conflict with the HIPAA standard of an 11 digit NDC Number, many programs will pad the product code or package code segments of the NDC with a leading zero instead of the asterisk.

Since a zero can be a valid digit in the NDC, this can lead to confusion when trying to reconstitute the NDC back to its FDA standard. Example: 12345-0678-09 (11 digits) could be 12345-678-09 or 12345-0678-9 depending on the firm's configuration. By storing the segments as character data and using the * as place holders we eliminate the confusion. In the example, FDA stores the segments as 12345-*678-09 for a 5-3-2 configuration or 12345-0678-*9 for a 5-4-1 configuration.

NDC Numbers on Claims

Some insurance companies are requiring that the National Drug Code (NDC) numbers be added to claims to ensure reimbursement or, in some cases, higher reimbursement. Why are they doing this?

In August 2000, the Department of Health and Human Services (HHS) published a final rule on "Standards for Electronic Transactions" that established NDC numbers as the standard medical data code set for reporting drugs and biologics in all standard transactions under the Health Insurance Portability and Accountability Act (HIPAA). To comply with those standards, some insurers may have started requiring NDC numbers on their claims. However, in February 2003, HHS repealed the NDC as the standard medical data code set for drugs and biologics in all but retail pharmacy transactions. At this time, no standard code set for drugs and biologics has been adopted for non-retail-pharmacy transactions. Until a new standard code set for drugs and biologics is adopted for non-retail-pharmacy transactions, insurance companies may continue to require NDC numbers or a combination of HCPCS codes (level two) and CPT vaccine codes for reporting drugs or biologics.


Tuesday, September 11, 2007

HCPCS Codes

About HCPCS Codes.
According to CMS statistics. Each year, in the United States, health care insurers process over 5 billion claims for payment. For Medicare and other health insurance programs to ensure that these claims are processed in an orderly and consistent manner, standardized coding systems are essential. The HCPCS Level II Code Set is one of the standard code sets used for this purpose. The HCPCS is divided into two principal subsystems, referred to as level I and level II of the HCPCS. Level I of the HCPCS is comprised of CPT (Current Procedural Terminology), a numeric coding system maintained by the American Medical Association (AMA). The CPT is a uniform coding system consisting of descriptive terms and identifying codes that are used primarily to identify medical services and procedures furnished by physicians and other health care professionals. These health care professionals use the CPT to identify services and procedures for which they bill public or private health insurance programs. Decisions regarding the addition, deletion, or revision of CPT codes are made by the AMA. The CPT codes are republished and updated annually by the AMA. Level I of the HCPCS, the CPT codes, does not include codes needed to separately report medical items or services that are regularly billed by suppliers other than physicians.

Level II of the HCPCS is a standardized coding system that is used primarily to identify products, supplies, and services not included in the CPT codes, such as ambulance services and durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) when used outside a physician's office. Because Medicare and other insurers cover a variety of services, supplies, and equipment that are not identified by CPT codes, the level II HCPCS codes were established for submitting claims for these items. The development and use of level II of the HCPCS began in the 1980's. Level II codes are also referred to as alpha-numeric codes because they consist of a single alphabetical letter followed by 4 numeric digits, while CPT codes are identified using 5 numeric digits.

In October of 2003, the Secretary of HHS delegated authority under the HIPAA legislation to CMS to maintain and distribute HCPCS Level II Codes. As stated in 42 CFR Sec. 414.40 (a) CMS establishes uniform national definitions of services, codes to represent services, and payment modifiers to the codes. Within CMS there is a CMS HCPCS Workgroup which is an internal workgroup comprised of representatives of the major components of CMS, as well as other consultants from pertinent Federal agencies. Prior to December 31, 2003, Level III HCPCS were developed and used by Medicaid State agencies, Medicare contractors, and private insurers in their specific programs or local areas of jurisdiction. For purposes of Medicare, level III codes were also referred to as local codes. Local codes were established when an insurer preferred that suppliers use a local code to identify a service, for which there is no level I or level II code, rather than use a "miscellaneous or not otherwise classified code." The Health Insurance Portability and Accountability Act of 1996 (HIPAA) required CMS to adopt standards for coding systems that are used for reporting health care transactions. We published, in the Federal Register on August 17, 2000 (65 FR 50312), regulations to implement this part of the HIPAA legislation. These regulations provided for the elimination of level III local codes by October 2002, at which time, the level I and level II code sets could be used. The elimination of local codes was postponed, as a result of section 532(a) of BIPA, which continued the use of local codes through December 31, 2003.

HCPCS Coding Process
The regulation that CMS published on August 17, 2000 (45 CFR 162.10002) to implement the HIPAA requirement for standardized coding systems established the HCPCS level II codes as the standardized coding system for describing and identifying health care equipment and supplies in health care transactions that are not identified by the HCPCS level I, CPT codes. The HCPCS level II coding system was selected as the standardized coding system because of its wide acceptance among both public and private insurers. Public and private insurers were required to be in compliance with the August 2000 regulation by October 1, 2002. The HCPCS Level II Coding Process/Criteria document describes HCPCS level II coding procedures and coding criteria, HCPCS Lookup and Search is done by external services.

Level II of the HCPCS is a standardized coding system that is used primarily to identify products, supplies, and services not included in the CPT codes, such as ambulance services and durable medical equipment, prosthetics, orthotics, and supplies (DMEPOS) when used outside a physician's office. Because Medicare and other insurers cover a variety of services, supplies, and equipment that are not identified by CPT codes, the level II HCPCS codes were established for submitting claims for these items. The development and use of level II of the HCPCS began in the 1980s. Level II codes are also referred to as alphanumeric codes because they consist of a single alphabetical letter followed by 4 numeric digits, while CPT codes are identified using 5 numeric digits.

HCPCS Coding classification
Like CPT codes, National codes are composed of five digits. Unlike CPT codes, HCPCS are alphanumeric. An alphanumeric code combines letters of the alphabet with numbers. In the National codes, one alpha letter is followed by four numbers.

Example: A4550 – Surgical tray

The code numbers are split more generally than those of the CPT. For example, codes starting with these alpha characters are:
    A – Ambulance services and general supplies
    D – Dental services
    J – Injections (medication codes)
    W, X, Y and Z are reserved for Local cod
Full HCPCS Codes index is:
HCPCS Codes Lookup
Lookup is the ability to get the information about the certain code by some partial info about it. One of the most powerful engines for misc Healthcare codes lookup is a BoostCluster engine powered by HipaaValidator.com. Specifically they provider quite good HCPCS Codes Lookup.

Thursday, September 6, 2007

HIPAA Validation

What is HIPAA?

In 1996, in an effort to reduce Health Care costs, Congress passed the Health Insurance Portability and Accountability Act of 1996, commonly known as HIPAA. One part of this legislation requires health plans and providers to use a common format when electronically communicating health information. The Secretary of the Department of Health and Human Services (HHS) was put in charge of determining a standard that could accommodate this requirement. ASC X12 Insurance Subcommittee developed a set of implementation guides to meet these requirements and were ultimately approved by HHS as the common format to meet the electronic data requirements. These implementation guides were based off the Version 4 Release 1 of the ASC X12 North American Standards for Electronic Data Interchange. HIPAA legislation required compliance of these standards by October 16, 2002, for large providers and payers. In December 2001, the President signed into law the Administrative Simplification Compliance Act (ASCA). This act allowed a one year extension to the mandatory compliance date making compliance mandatory by October 16, 2003.

HIPAA Regulations regarding Transactions Validation

In this time of increasing financial, operational and regulatory pressures on health plans, payers and providers, executives are discovering that electronic transactions present as many challenges as they do opportunities.

HIPAA legislation mandated the use of standard transactions and code sets between trading partners, in an attempt to ease the burden of telephonic and paper communication between payers, providers, employers and other stakeholders. However, as almost everyone has discovered many backend processes and systems have very specific data content and format requirements, allowable under HIPAA, in order to achieve the highest possible levels of automation.

Contrary to the intent of the law, in many cases, automation rates have gone down, not up-creating unintended costs and negative impacts for payers, providers and consumers. HIPAA transactions are not the only standards that healthcare organizations must support to be effective and efficient. Other standards such as HL7, NCPDP, NSF, UB92 and even proprietary file formats must be supported, given the wide variety of trading partner requirements.

All these requirements have created a number of questions that organization leadership should address to be responsive to their markets. The answers to these questions can determine whether an organization can create and maintain a strategic advantage leveraging electronic trading relationships.

HIPAA Validation Complexities

As healthcare providers prepare for the HIPAA transactions compliance deadline on October 16, 2003, many are relying on clearinghouses to resolve the issues that surround reformatting, editing and transmitting of the new, standardized electronic transactions. These providers intend simply to continue a long-standing practice of passing claims and other transactions to a clearinghouse, which will transform, edit and forward the transactions to specified payers for processing and payment. However, though many healthcare CEOs, CFOs and CIOs may not understand all of the complexities of HIPAA validation, some are becoming increasingly concerned that reliance on their clearinghouses may not ensure continued positive cash flow after October 16th. In many cases, their concern is justified.

Succinctly stated, HIPAA transactions validation goes far beyond providing a transaction in an agreed-upon format. HIPAA validation also applies to several thousand combinations and permutations of correct data elements, and is subject to varying interpretation of the regulations by certifying organizations and participating trading partners. In light of these complexities, your organization leadership should pause and verify that your clearinghouse will accept the responsibilities and perform the role that you expect.

Should you trust your clearinghouse to ensure that each transaction is successfully validated before sending it to the payer for payment? Perhaps you do not feel as confident of the clearinghouse as you would like, but do not know what questions to ask in order to increase your comfort level.

HIPAA Validation in Action

There are several HIPAA Validation solutions on the market, however the most modern and rapidly developing one is HIPAA Vadalition service provided by HIPAAValidator.com.

HIPAA Compliance Validator is a complex online solution based on the Boost Clusters engine, proving data handling, validation, conversion, audit report generation. The main goal is to help our customers identify the problems with their HIPAA document at the early stages and to eliminate the costs related to errors and claim returns. HIPAA Compliance Validator is an intermediate step in between the creation of the document by Provider and receiving of this document by Payer. You can integrate the service on any step of this process - it can be used by Providers to ensure that the claims are valid and to reduce the looses and by Payers to make sure that claims, received from Providers are valid and can be sent for further handling to internal systems.

How it works

HIPAA Compliance Validator system contains of several layers: Front-end, Inbound security, De-identification, Validation and Conversion, Report creation, Outbound security. Data workflow is as below.

Front-ends - user submits the file either through the online form (convenient for single document submission) or using the In-Stream technology of Boost Clusters engine. After data is received it gets SSL encrypted with highest level possible within current industry standards. This is Inbound security layer. Such extreme pre-cautions are required to prevent any data leaks during the whole process. Due to the Inbound security layer, there is no need to worry about the data disclosures or leaks. As a part of the inbound security process, HIPAA Validator performs data de-identification to prevent any parts of the system from accessing the secure personal information that may be sent in the HIPAA document. After that, secured data comes to validation and conversion. All these steps are powered by Boost Clusters engine which provides full set of compliance validation procedures. For user's convenience it is possible to get the XML representation of the HIPAA file. This XML data can be then used in the wide variety of the XML routing and mapping engines to satisfy your trading partner agreements. Based on the validation results user gets the Audit report with the detailed explanations on all the errors current document contains with the recommendations on errors elimination. To prevent data from being lost or stolen on the outbound end, Outbound security layers has been added to finalize the security cycle.

Wednesday, September 5, 2007

New NPI Lookup system

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.