Standard Unique Health Identifier for Healthcare Providers

2. Data Elements and Data Dissemination

Proposed Provisions

In the preamble of the May 7, 1998, proposed rule, in section IV, ‘‘Data,’’ we listed the data elements that we proposed to include in the NPS. We solicited comments on the inclusion and exclusion of those data elements and the inclusion of other data elements that the public believed appropriate. We asked how the NPS could be designed to make it useful, efficient, and low-cost. In that same section, we also posed data questions and discussed options for NPS data structures. Section II.C.1. of this preamble, ‘‘NPS Data Structures,’’ contains the comments and responses and decisions made regarding NPS data structures. As a result of those decisions, some data elements that were included in the list of proposed data elements published in the May 7, 1998, proposed rule will not, in fact, be included in the NPS database. Therefore, the information in section II.C.1. of the preamble should be kept in mind in reading this section. In the preamble of the May 7, 1998, proposed rule, in section V., ‘‘Data Dissemination,’’ we proposed two levels of dissemination of information from the NPS:

•(1) Level I—To the entity(ies) performing the enumeration functions. The(se) entity(ies) would have direct access to the NPS and to all the data elements in the NPS; and

•(2) Level II—To the general public. The general public would be able to request and receive selected data elements, excluding those that are protected by the Privacy Act. (Requests for Privacy Act-protected data and Freedom of Information Act (FOIA) requests would be handled in accordance with existing HHS policies.) The May 7, 1998, proposed rule contained a table indicating the level of dissemination of the NPS data elements. We proposed that we would charge fees for data and data files, but that the fees would not exceed the costs of dissemination (63 FR 25338). We solicited comments on the information that should be available in paper and electronic formats and the frequency with which information should be made available.

Comments and Responses on Data Elements and Data Dissemination

Comment: An overwhelming number of commenters said that the NPS should contain only the data elements required to communicate with and uniquely identify and assign an NPI to a health care provider. They believed this information should be the kind that could effectively be maintained at the national level, leaving the more complex and volatile data to health plans to capture and maintain, as they currently do. Many commenters listed the specific data elements that they recommended we remove from the list presented in the May 7, 1998, proposed rule. The majority of commenters believe that, as a result of the removal of the data elements not needed for enumeration and communication, the NPS would be easier and less expensive to maintain and would operate more efficiently.

Response: To be valuable, the NPS must be accurate, up to date, and meet its intended purpose in the most feasible way. The NPS must collect information sufficient to uniquely identify a health care provider and assign it an NPI and must collect information sufficient to communicate with a health care provider. The data elements that we have retained are necessary to uniquely identify and communicate with a health care provider. Our decision to reduce the composition of the NPS to the data elements needed for unique identification and communication removes many of the data elements that were proposed to comprise the NPS in the May 7, 1998, proposed rule. The comments and responses that follow contain additional information and rationale concerning our decision to include or exclude certain data elements.

Comment: Some commenters said that collecting but not validating certification or school information would make that information meaningless. Most commenters did not believe the NPS should collect certification or school information in the first place because it would not be useful in uniquely identifying the individual applying for an NPI. They believe that collection and validation of this information should continue to be done by health plans in their health care provider enrollment processes. Most commenters supported the collection of credential designation(s) (for example, M.D., C.S.W., and R.N.), license number(s), and State(s), which issued the license(s) for individual health care providers whose taxonomy classifications require licenses.

Response: We agree with commenters that it would be costly to collect, validate, and maintain certification and school information. We do not believe the NPS should replicate unnecessarily the work carried out by health plans. We agree that health plans, which do this work now, should appropriately continue to do so. The NPS will capture an individual health care provider’s license number (if appropriate), the State which issued the license (multiple occurrences of both data elements), and the credential designation(s). The credential designation(s) (called‘‘Provider’s credential designation’’ in the May 7, 1998, proposed rule) will be captured in the data element ‘‘Provider credential text,’’ which will be a repeating field. This data element was renamed to make it compatible with X12N HIPAA data dictionary naming conventions and also to avoid giving the impression that the NPS will be validating the credentials. The license number and State in which it was issued will be useful to health plans in matching NPS records to their health care provider files. As a result of the decision not to collect certification and school information, the following data elements will not be included in the NPS:

• Provider certification code;
• Provider certification (certificate) number;
• School code;
• School name;
• School city, State, country;
• School graduation year.

Comment: Commenters did not see value in the NPS capturing ‘‘Provider’s birth county name.’’ They believe the State name and country (the latter required if the health care provider was not born in the United States) would be sufficient for identification purposes.

Response: We agree. The ‘‘Provider’s birth county name’’ data element will be excluded from the NPS.

Comment: Some commenters suggested that the ‘‘Taxpayer Identifying Number’’ (TIN) be added to the NPS. They believed this was needed to match NPS records to health plans’ health care provider files and that it could help in unique identification.

Response: We agree that the numbers used to report income taxes will beuseful in uniquely identifying health care providers.

According to the Internal Revenue Service (IRS), three numbers (known as‘‘Taxpayer Identifying Numbers,’’ or TINs) may be used (depending on circumstances) to report income taxes: (1) The Social Security Number (SSN), assigned by the Social Security Administration to individuals; (2) the IRS Individual Taxpayer Identification Number (ITIN), assigned by the IRS to individuals who are not eligible to receive Social Security Numbers; and (3) the Employer Identification Number (EIN), assigned by the IRS to organization health care providers (that is, health care providers that would not be assigned ‘‘Entity type code’’ 1 NPIs). For purposes of being assigned NPIs, health care providers will be asked voluntarily to supply their SSN or IRS ITIN (if they are individuals who would be assigned an ‘‘Entity type code’’ 1 NPI), or will be required to supply their EIN (if they are organizations that would be assigned ‘‘Entity type code’’ 2 NPIs). Requesting the SSN from individual health care providers will dictate that we include on the NPI application/update form appropriate disclosure and Privacy Act statements.

Comment: Some commenters suggested that Medicare and Medicaid sanction information be added to the NPS. One commenter wanted to know where sanction data would be housed and who would maintain these data.

Response: The NPS will not contain sanction data or indicators that sanction data exist. Sanction data were not included in the data element list published in the May 7, 1998, proposed rule. While maintainers of sanction databases may incorporate the NPI into their databases to enable searches by NPI, the NPS will not house sanction information. The Web address for the Office of Inspector General sanctioned health care providers file is http://exclusions.oig.hhs.gov/.

Comment: Some commenters said that ‘‘License revoked indicator’’ and ‘‘License revoked date’’ should be included in the NPS.

Response: The NPS will not capture this or similar information. The uniqueness of the health care provider can be established without this information. This information would more appropriately be collected by health plans.

Comment: A number of data elements were suggested to be added to the NPS. These included ‘‘Owner of the provider,’’ ‘‘Practice type control code’’ (office-based, hospital-based, Federal facility practice, and other), ‘‘Source of information for certification,’’ ‘‘Provider type,’’ and ‘‘Provider specialty code.’’

Response: The May 7, 1998, proposed rule did not propose that the NPS collect health care provider ownership information. This information is volatile and already resides on most health plans’ health care provider enrollment files. Practice type control information is not required to uniquely identify or classify a health care provider for NPS purposes; therefore, it will not be included in the NPS. ‘‘Source of information for certification’’ will not be captured because, as explained earlier in this section, certification information will not be collected by the NPS. The definitions of ‘‘Provider type’’ and ‘‘Provider specialty code’’ may differ from one health plan to another; the NPS will capture the type(s), classification(s), and area(s) of specialization as described in the Healthcare Provider Taxonomy Code set. By capturing this information, we take into account the specialty classifications as required by HIPAA. The taxonomy can be viewed at this Web site: http://www.wpc-edi.com/taxonomy/.

Comment: A commenter suggested that a health care provider’s ‘‘pay-to address’’ be added to the NPS. Another commenter stated that health plans will use the health care provider’s mailing address as the pay-to address. Another commenter suggested that HHS consider electronic data interchange (EDI) addresses for inclusion in the NPS.

Response: In most situations, a health care provider’s ‘‘pay-to address’’ is its mailing address. Therefore, we do not believe it is necessary to add a ‘‘pay-to address’’ to the NPS. Because EDI addresses are not standardized at this time, they will not be included in the NPS. The composition of the NPS will be revised if necessary in the future.

Comment: Several commenters suggested adding the name of the establishing enumerator or agent and the name and telephone number of the enumerator who made the last update to the NPS. They believe that this information would help ensure the accuracy of the database by preventing multiple enumerators from updating or attempting to update the same records.

Response: As discussed in section II. B. 2. of this preamble, ‘‘Health Care Provider Enumeration,’’ there will be one entity, under HHS direction, that will be charged with enumeration functions. The decision to use a single enumerator renders the data elements proposed by these commenters unnecessary. The ‘‘Establishing enumerator/agent number’’ will not be included in the NPS.

Comment: One commenter suggested we add ‘‘Provider status’’ and ‘‘Date of deactivation’’ to the NPS.

Response: In section II. A. 2. of this preamble, ‘‘Definition of Health Care Provider,’’ we describe the reasons why an NPI may be deactivated. We have added to the NPS two new data elements: ‘‘National Provider Identifier deactivation reason code’’ and‘‘National Provider Identifier deactivation date.’’ These data elements will capture the information suggested by this commenter. (It should be noted that ‘‘Provider’s date of death’’ will be excluded as a data element from the NPS. Fact of death and resulting deactivation date will be captured in the two new data elements.) We have also added a data element called ‘‘National Provider Identifier reactivation date,’’ which will capture the date that a health care provider’s NPI is reactivated.

Comment: Several commenters suggested adding ‘‘Cross reference to replacement NPI.’’ They thought it would be important to link former and current NPIs.

Response: In section II. A. 2. of this preamble, ‘‘Definition of Health Care Provider,’’ we explain that an NPI is designed to last indefinitely. There may, however, be an unusual circumstance that would justify a health care provider’s request to be issued a new, different NPI. In these situations, the NPS will link the new, or replacement, NPI to the previous NPI(s) of that same health care provider. (By ‘‘same health care provider,’’ we mean an entity with exactly the same data elements, or string of NPS data.) We will add two new data elements to the NPS: ‘‘Replacement NPI’’ and ‘‘Previous NPI.’’ Both will be repeating fields (see ‘‘Data Status’’ preceding the National Provider System Data Elements and Data Dissemination table). When a user retrieves the NPS record of a health care provider, either of those fields may contain data. (If neither field contains data, the health care provider has had only one—its original—NPI.) The user can then retrieve the related NPS record by requesting the record of the NPI appearing in the ‘‘Replacement NPI’’ or the ‘‘Previous NPI’’ field, whichever is appropriate.

Comment: One commenter suggested that ‘‘Effective from’’ and ‘‘Effective through’’ dates be added for telephone numbers and addresses.

Response: We expect that the NPS will be designed to associate dates with the information about a health care provider, thus creating a history of a health care provider’s record. When changes are made to a health care provider’s telephone number or address,that health care provider’s record will include the dates of those changes.‘‘Effective from’’ and ‘‘Effective through’’ dates for telephone numbers and addresses may not hold true; there could be unexpected situations that could cause changes to occur sooner or later than reported. We believe it will be more accurate to include a date to reflect each time a change is made in this information.

Comment: A commenter suggested that the On-line Survey Certification and Reporting System (OSCAR) number be maintained after the initial load of Medicare providers, and that the NPS include a ‘‘Facility type’’ indicator for OSCAR providers.

Response: As explained earlier in section II. B. 2. of this preamble,‘‘Health Care Provider Enumeration,’’ we are evaluating the feasibility of populating the NPS with existing Medicare provider files. If this is done, the OSCAR number, which is a Medicare-assigned number, will be captured in the NPS automatically. Whether or not we populate the NPS with Medicare files, the NPI application/update form will collect health care provider identification numbers that are assigned by certain health plans (including Medicare) and other organizations. Health care providers that apply for NPIs will be able to furnish these numbers (‘‘Other provider identifier’’) and to indicate the type of number being furnished (for example, OSCAR, UPIN, DEA, and Medicaid) (‘‘Other provider identifier type code’’), on the NPI application/ update form. These will be optional and repeating NPS data elements. The NPS will capture as many ‘‘Other provider identifier’’ entries and the corresponding ‘‘Other provider identifier type code’’ entries as are reported on the NPI application/update form. The NPS will apply changes or updates to the ‘‘Other provider identifier’’ or ‘‘Other provider identifier type code’’ when health care providers notify the NPS of changes to this information.

The NPS will not require a ‘‘Facility type’’ indicator for health care providers with OSCAR numbers. It will collect the Healthcare Provider Taxonomy Code on the NPI application/update form. Comment: Several commenters suggested the NPS retain the health care provider mailing and health care provider practice (provider location) phone number, facsimile number, and electronic mail address only during the initial assignment of NPIs, and then discontinue maintenance of this information.

Response: These data elements are needed for communication with the health care provider. HHS may need to communicate with a health care provider at any time during the implementation period or after. Therefore, these data elements will be maintained beyond the initial assignment of NPIs. In section II. A. 5. of this preamble, ‘‘Implementation specifications for Health Care Providers, Health Plans, and Health Care Clearinghouses,’’ we are requiring health care providers who are covered entities to update their required NPS data, which includes the data elements noted in the comment above, whenever changes occur.

Comment: Many commenters suggested that several data elements be repeated; for example: ‘‘Provider’s other name’’ and ‘‘Provider’s other name type’’; ‘‘Other provider number’’ and‘‘Other provider number type’’; ‘‘Provider license number’’ and‘‘Provider license State’’; ‘‘Provider classification’’; the data elements associated with schools; and the data elements associated with credentials.

Response: The data element table appearing in the May 7, 1998, proposed rule did not indicate repeating fields. In the National Provider System Data Elements table at the end of this section, repeating fields are noted as such. The NPS will contain as many repeating fields as there is information for ‘‘Provider other last or other organization name’’ and ‘‘Provider other last or other organization name type code.’’ As mentioned earlier, the NPS will also be able to accommodate multiples of other health care provider numbers in the data element ‘‘Other provider identifier’’ and types of other health care provider numbers in the data element ‘‘Other provider identifier type code.’’ The NPS will accommodate multiple entries for ‘‘Provider license number’’ and ‘‘Provider license State.’’ As explained earlier, the school information will be excluded from the NPS. ‘‘Provider credential text’’ (for example, M.D. and D.D.S.) will be a repeating field. These repeating fields are either optional or situational and will not be validated.

Comment: Many commenters asked that ‘‘Provider’s race’’ be removed from the NPS. They did not believe it would be accurately reported. They stated that there are inconsistent definitions for‘‘race’’; they did not understand the purpose for collecting this information.

Response: We understand and appreciate the comments stating that the NPS should be capturing only what is needed for unique identification of and communication with a health care provider. While collection of race and ethnicity data could support a number of important research activities, this information is not needed to uniquely identify a health care provider; thus, we have concluded that the NPS is not the appropriate vehicle for collecting this information. Therefore, we will not collect these data elements even on an optional basis.

Comment: Several commenters suggested that a number of other data elements be excluded from the NPS: all user-requested data elements (these were denoted by a ‘‘U’’ in the data element list in the May 7, 1998, proposed rule), ‘‘Other provider number,’’ ‘‘Other provider number type,’’ ‘‘Organization type control code,’’ ‘‘Provider certification code,’’ ‘‘Provider certification (certificate) number,’’ ‘‘Provider license number,’’ ‘‘Provider license State,’’ ‘‘School code,’’ ‘‘School name,’’ ‘‘School city, State, country,’’ ‘‘School graduation year,’’ ‘‘Provider classification,’’ ‘‘Date of birth,’’ all electronic mail addresses and fax numbers, ‘‘Date of death,’’ ‘‘Provider sex,’’ and ‘‘Resident/Intern code.’’

Response: We stated in the previous response that ‘‘Provider race code’’ (which was a user-requested data element in the list included in the May 7, 1998, proposed rule) will not be retained. We discussed all other data elements presented as user-requested data elements in the list in the May 7, 1998, proposed rule in previous comments and responses except for ‘‘Organization type control code’’ and ‘‘Resident/Intern code.’’ These two latter data elements will be excluded; they are not needed for the unique identification of or communication with a health care provider.

Comment: Several commenters questioned the use of ‘‘optional’’ data elements, believing that ‘‘optional’’ information will rarely be furnished and, if it is furnished, may not be reliable and probably would not be kept current.

Response: Certain information about health care providers that is desirable to uniquely identify them in order to assign NPIs cannot be required to be furnished. ‘‘Situational’’ data elements should not be confused with ‘‘optional’’ data elements. ‘‘Situational’’ data elements are required if a certain situation, or condition, exists. ‘‘Optional’’ data elements do not have to be supplied at all. For example, ‘‘Provider other last or other organization name’’ is optional. A health care provider may choose not to report a former name or a professional name. We have attempted to make as few data elements as possible ‘‘optional’’ in the NPS.

Comment: Several commenters suggested that data element names, qualifiers, and definitions be consistent with the X12N HIPAA data dictionary.

Response: The NPS data element names, qualifiers, and definitions, wherever possible, are mappable to those in the X12N HIPAA data dictionary and are compatible with X12N naming conventions. We believe the mapping capability and naming convention compatibility are essentially what the commenters wanted and believe we have satisfied their concerns.

Comment: Two commenters suggested that the Drug Enforcement Administration (DEA) number be collected from health care providers that have one.

Response: The DEA number is an example of an ‘‘Other provider identifier.’’ The DEA number can be accommodated in this field in the NPS. We recognize that mapping between DEA numbers and NPIs is very important for the conversion of retail pharmacy files during NPI implementation. Therefore, we will collect the DEA number in the ‘‘Other provider identifier’’ field if it is reported on the NPI application/update form and will carry the fact that it is a DEA number by setting the ‘‘Other provider identifier type code’’ to indicate that.

Comment: Several commenters suggested that we publish a data model and record layout or both describing in detail the data elements, field lengths, format, repeating fields, and required and situational fields.

Response: The data element table in this preamble includes an indication of‘‘required,’’ ‘‘optional,’’ or ‘situational’’ for each data element, and repeating data elements are noted as such. More detailed information, as requested in the comment, will be posted to the CMS Web site (http://www.cms.hhs.gov) when it becomes available during the NPS design.

Comment: Several commenters said an audit trail of NPI updates is needed for qualified users. This would indicate which enumerator updated which fields.

Response: The NPS will construct an audit trail. We expect that the audit trail would include the date a change was made, the old value, the new value, and the initiator of the change. As stated in section II. B. 2. of this preamble,‘‘Health Care Provider Enumeration,’’ there will not be multiple enumerators. The NPS will contain a date (‘‘Last update date’’) that will indicate when a change was made to a health care provider’s record. Extracts containing NPS changes will be made available in HHS-determined format and media to satisfy requests from approved users (see later discussion in this section of the data dissemination strategy).

Comment: Several Medicaid State agencies suggested that the Healthcare Provider Taxonomy Code set contain all health care provider types and specialties needed by Medicaid plans. Another commenter asked that the code set reflect services provided by pharmacists. Another stated that the code set did not contain a category for pain medicine. Several other commenters said the taxonomy code set is inconsistent.

Response: Until recently, this code set was maintained through an open process by the National Healthcare Provider Taxonomy Committee for use in Accredited Standards Committee X12N standard transactions. It is now maintained through an open process by the National Uniform Claim Committee. The web site at which the code set is available is http://www.wpc-edi.com/ taxonomy/. The web site contains information on how changes to the code set can be requested. (Note: Pharmacy service providers and physicians whose specialization is ‘‘Pain Medicine’’ are included in the code set.)

Comment: Several commenters suggested that the NPS contain a feature whereby the Healthcare Provider Taxonomy Code set classifications will be available for selection when applying for an NPI.

Response: We will consider this comment in the design of the NPI application/update form.

Comment: Many commenters supported the creation of an industry-wide forum to determine the data element content, identify the mandatory and optional data elements, and determine the data dissemination requirements of the NPS. They recommended that WEDI foster such a group.

Response: WEDI is named in the Act as an external group with which the Secretary must consult in certain
circumstances in standards development. To address these issues, WEDI formed several workgroups, which consisted of representatives from every aspect of the health care industry. Following the workgroups’ meetings, WEDI supplied HHS with comments on NPS data, data dissemination, and other issues, supplementing the comments WEDI provided to HHS during the public comment period. We have considered these comments in developing this final rule.

Comment: Most commenters did not favor the two-level data dissemination approach presented in the May 7, 1998, proposed rule but favored instead a three-level approach:

• Commenters agreed that only the entity performing the enumeration functions and HHS should have access to the entire NPS.
  
• Commenters did not want Privacy Act restrictions violated but believe that our approach denied health plans and certain other health care industry entities information that they needed in order to process HIPAA transactions, while it gave the general public an excessive—and unnecessary—amount of information. They said that health plans and other health care industry entities required certain Privacy Act-protected data in order to accurately match their health care provider files with NPS data to effectively implement HIPAA requirements. Many suggested that health plans and health care clearinghouses be permitted to obtain copies of the database and periodic update files so that they can maintain files that are continually consistent with the NPS. Some commenters suggested an on-line query and response system be developed for health plans to verify a health care provider’s NPI. Others wanted electronic transactions designed that could be sent to the NPS with a response returned. These transactions might request all available data, regional data, new records only, and updated records only. Some commenters suggested that health plans have batch and interactive access capabilities to the NPS, stating that health plans will require daily batch updates of new and changed records, particularly during the implementation period. Some suggested that changed records be available for electronic download daily and weekly, and monthly by CD ROM and diskette. Still others preferred that health care entities receive data through the Internet with secure identifiers.
  
• One commenter stated the NPS data should be used strictly for enumeration and that no NPS data should be made available to the public. This commenter recommended that the public and others obtain NPIs from the health care providers themselves, not from the NPS. Some commenters believe it inappropriate for the general public to look to the NPS as the source of any but the most general types of information about health care providers. Some commenters expressed concern that public release of too much information (particularly, full addresses) could subject health care providers to receipt of junk mail and other unsolicited materials.
  
• Commenters recommended that agreements be signed by anyone receiving NPS data to ensure the information released would not be used for marketing or mailing list generation or sold or transferred to another entity.
  
• Several commenters stated that personally identifiable data about health care providers, contained in the NPS, should be available to researchers for clinical and financial outcomes analyses after appropriate agreements are signed.
  
• One commenter suggested read-only access to the NPS data for all users.
  
• Several commenters stated that the data dissemination policy should be consistent with the routine uses of NPS data as published in the NPS System of Records Notice (63 FR 40297).

The three dissemination levels suggested by commenters were:

Level 1—Available to HHS and the entity with which HHS contracts to perform the enumeration functions.

Level 2—Available to health plans and certain other health care industry entities that require certain Privacy-Act protected data to match their health care provider files to NPS data.

Level 3—Available to the general public.

Response: In order to keep costs low, we must make the NPS data dissemination strategy as efficient and uncomplicated as possible. The number of formats and access options will need to be limited.

We view the NPS as a health care provider identification and enumeration system, capturing the information required to perform those functions and disseminating information needed by health plans and other entities to effectively carry out the provisions of HIPAA. We agree with the majority of commenters who stated that health plans and certain other health care industry entities require NPS data, including some data that are protected by the Privacy Act, in order to effectively conduct HIPAA transactions. (Privacy Act-protected data are those that reveal or could reveal the identity of a specific individual when used alone or in combination with or linked to one or more data elements.)

Comment: Some commenters suggested that a health care provider be able to access its own NPS data through the Internet to ensure its accuracy and to facilitate updating the information.

Response: This comment will be considered in the design of the NPS; if it is determined to be feasible, this
access will be made available.

Comment: Several commenters supported charging reasonable fees or subscription rates for web-based data access options; for example, HHS could charge an annual subscription fee for unlimited downloads and a different subscription fee for monthly downloads. Some commenters asked if on-line access charges would be based on time or on a per file access basis. Some commenters believed that usage fees should not be limited to the cost of producing the data but should be linked to the costs and value of establishing and using the NPS.

Many commenters stated that the enumerator(s) should not have to pay for NPS data.

One commenter, who had suggested the enumerator be a public and private sector trust, suggested that dissemination fees be established and administered by the public and private sector trust.

Response: The design of the NPS will facilitate making information available in an efficient manner, which will
involve the use of the Internet. We are reviewing the issue of charging fees, and intend to consider charging fees to the extent our authority permits.

Final Provisions (§ 162.408(b) and (f))

The NPS Data Elements Table lists the data elements that we expect to collect about a health care provider and which will be included in the National Provider System (NPS). The data element table is not intended to be used for data design purposes. During NPS design and development, the names and attributes of the data elements may be revised. We are including this listing to show readers the kind of information that we expect will be collected about health care providers or that will be NPS-generated (for example, the NPI) about health care providers. The table does not include systems maintenance or similar fields.

Description of the information contained in each column of this table: Data Element Name: The name of the data element residing in the NPS. Description: The definition of the data element and related information. Data Status: The instruction for furnishing the information being requested in the data element. The abbreviations used in this column are as follows:

Required (R): Required for NPI assignment.

NPS-generated (NG): Generated or assigned by the NPS.

Optional (O): Not required for NPI assignment.

Situational (S): If a certain condition exists, the data element is required. Otherwise, it is not required.

Repeat (RPT): Indicates that the data element is a repeating field. A repeating field is one that can accommodate more than one separate entry. Each separate entry must meet the edits, if any, designated for that data element.

Data Condition: Describes the condition(s) under which a ‘‘Situational’’ data element must be furnished.

NOTE: The abbreviation NA means ‘‘not applicable.’’

Entity Types: The ‘‘Entity type codes’’ to which the data element applies. See the description of the data element‘‘Entity type code’’ in the table.

Use: The purpose for which the information is being collected or will be used.

I: The data element supports the unique identification of a health care provider.

A: The data element supports administrative implementation specifications. Dissemination of data from the NPS is a complex process. It must be responsive to requests from covered entities for NPS information that they need in order to comply with HIPAA. We expect a high volume of such requests, primarily from health plans, once NPIs begin to be assigned. At the same time, the dissemination process must ensure compliance with the provisions of the Privacy Act, the Freedom of Information Act, the Electronic FOIA Amendments of 1996, and other applicable regulations and authorities, and must be consistent with the NPS System of Records Notice, which was published on July 28, 1998. We expect to make routinely available, via the Internet and on paper, HHS-formatted data sets that will contain general identifying information, including the NPI, of enumerated organization health care providers and subparts of such health care providers (as described earlier in this preamble). Because of complexities that are inherent in disseminating data from the NPS, it is necessary to eliminate from the NPS Data Elements Table the column that, in the proposed rule, indicated the data dissemination level. Our data dissemination strategy and the process by which it will be carried out will be described in detail at a later date and published in a notice in the Federal Register.

D. New and Revised Standards

Comments and responses on new and revised standards can be found in the Transactions Rule (65 FR 50343). Generally, we may modify a standard after the standard has been in effect for at least a year, unless we determine a modification is necessary sooner in order to permit compliance with the standard. The Secretary may not require compliance with a modification until at least 180 days after the modification is adopted. We will consider requests for modifications to the standard unique health identifier for healthcare providers.

[Top of Page] [Previous] [Next]