HimSS logo

National Committee on Vital and Health Statistics (NCVHS)

 NCVHS Standards and Security Subcommittee
NPI Panel Testimony
January 24, 2007

Introduction

Distinguished members of NCVHS and its Standards and Security Subcommittee, I am honored to be here today to testify on the following:

*Siemens education and outreach initiative relative to NPI
*Siemens issues relative to NPI
*Concerns specific to our industry’s interests;
*Siemens evaluation of industry readiness to successfully respond to NPI implementation beginning in May 2007.

My name is Mitch Icenhower, and I am the Senior Director of Revenue Cycle Solutions for Siemens Medical Solutions, USA.  I am testifying today on behalf of my firm, Siemens Medical Solutions, USA, which provides healthcare information technology solutions to support the healthcare administrative process.

I would like to acknowledge the Healthcare Information and Management Systems Society (HIMSS) who facilitated my participation on today’s panel.  While a long time leader in healthcare systems and technology, HIMSS marked 2006 with focus on financial and business administrative technology and systems and integration of these systems with clinical systems.

Siemens provides healthcare information technology solutions for over 1200 customers.  In addition, we connect with over 200 payers in the exchange of HIPAA administrative transactions.  As such, Siemens has proactively participated in industry education on the National Provider Identifier (NPI) initiative and continues to keep pace with industry issues and readiness.  In turn, we have shared industry insights and information with our customers via our website and by directly emailing important information to them.  We have educated our customers as well as our vendor partners, via web-casts and memos, on our own progress and timelines to support the NPI.  We have also set up an email address to accept customer questions relative to this topic.

Siemens has dedicated a great deal of analysis and development over the past few years to ensure that we are prepared to support and process the NPI.  We have rewritten software in all relevant applications as well as clearinghouse capabilities.  Our commitment to help ready our customers is evident in the 15,000 plus hours that we dedicated to the effort.  These hours represent our commitment to updating patient management and patient accounting/billing applications which include the NPI on provider master files and relevant databases, input screens and interfaces.  Additionally, we developed billing logic options to provide customers with the flexibility to support provider identifying information at the payer specific and/or service specific level.  This flexibility was developed due to the early confusion concerning how providers would enumerate, and how payers would interpret provider information in order to identify the provider at the level of the previous legacy identifier.  Validation routines were developed in our software, using the Luhn algorithm, to assist customers with entering valid NPIs into their provider master files.  Siemens solutions were also developed incorporating the WEDI Dual Use strategy to allow for a smoother transition.  This will facilitate a transition based on individual provider and payer readiness, and ensure the ability to accommodate a phased approach.  In addition to customer communications and education, an online NPI submission process has been set up to provide customers with a mechanism by which they can communicate their NPIs via an automated process.

Siemens continues to dedicate efforts to NPI readiness, and we expect to fund another 5000 plus hours in the next few months to:

  • Continue to monitor industry readiness
  • Collect NPIs from provider customers
  • Determine payer support strategy and readiness for testing
  • Perform testing and respond to any issues raised

In terms of our state of readiness, Siemens has delivered NPI software, and customers have had the opportunity to begin loading their facility and physician provider NPIs.  However, our ability to initiate the reporting of NPIs on transactions is dependant on other trading partners’ readiness.

In late summer of 2006, Siemens surveyed approximately 200 payers to determine their readiness for NPI implementation.  Only 10% of the payers Siemens interacts with responded to that survey or have met with us via a conference call to discuss their NPI support strategy.  The challenge for Siemens, as well as the entire industry, is the readiness of all the players (providers, payers, vendors) to ensure a successful implementation to move to the NPI.   As a result, even those that are ready to support and test cannot do so, since other trading partners who are important to the flow of transactions and the success of the implementation may not be at the same level of readiness.

Although we have only heard from a small percentage of our trading partners, we are concerned by the significant variance in their NPI support strategy.  This is causing some re-work to our systems, and we foresee that these differences will have an impact on providers.  One example that we have identified involves a major national payer who does not plan to return on the 835 transaction the NPI that was submitted on the 837 transaction.  This payer will require the provider to choose one NPI that will be reported on the returned 835 transaction, regardless of the NPI that is submitted on the 837 transaction.  Although this is not the intent of the NPI rule, the payer is technically compliant because they are accepting, processing and returning an NPI.

Another contributing and significant factor impacting industry readiness is the ability for payers to create crosswalks to current legacy identifiers due to the unavailability of a database to access NPI information.  The lack of a process to allow the dissemination of NPI information, combined with the lack of progress of providers to share their NPIs with trading partners, hinders our testing and implementation progress.  In addition, there is a significant lack of direct communication from payers to providers regarding their NPI submission process as well as their approach for building a crosswalk.  Siemens has learned that some payers will build their crosswalk when the NPI is sent during the dual use process, while others are requesting that specific information appear on the claim in order to recognize the provider.  Although many payers have supplied newsletters and web site announcements, in many cases no direct communication has occurred.  If this information is not communicated to the providers via a direct communication, there is a high likelihood that many providers are not yet aware of their payers’ plans.

Siemens has been communicating with both providers and payers, and has encountered other signs of the lack of industry readiness as a result.

  • On a recent conference call with payers, one payer indicated that some providers in their state were just learning about the NPI.  This was surprising, given the fast approaching implementation date.
  • There is also a concern with industry interpretation of the dual use strategy.  At least one large payer plans to require the provider to send a transaction with the NPI, receive a rejection, and subsequently send the transaction with the legacy identifier in order for it to be processed.  This is certainly not the intent of the dual use strategy, and does not improve administrative simplification for the provider or the payer.  There are other payers who plan to handle the placement of the NPI versus the legacy identifiers differently than was defined by the WEDI recommendation.  This does not lead to a simplified implementation or a common approach.  
  • Additionally, there are payers who plan to strictly enforce the May 23rd deadline by rejecting any claim with a secondary identifier.  Given the lack of industry readiness, this is bound to create reimbursement problems for providers.

In addition to significant readiness concerns, other industry issues have come to light with the NPI implementation.  Payers are requiring taxonomy codes, as well as other data, to build crosswalks to their legacy identifiers to accommodate various provider enumeration decisions.  However, payers may not require the same taxonomy code or other data to appear on a claim for a particular service.  This will require the provider as well their vendor, to support and manage taxonomy code assignment that is dependant on the payer to whom a transaction is being sent.  This will impact greatly on the ability to implement a “Provider-to-Payer-to-Payer Model” for the payment of a claim by multiple payers, as described in the 837 Implementation Guide. This model is the desired goal of the industry (HIPAA) in our continued efforts to facilitate a more stream-lined, automated healthcare transaction process that is beneficial to both providers and payers.

Additionally, through internal and limited external testing, we are beginning to discover other issues.  An example is the lack of data consistency between the 837 claim transaction and the 835 remittance transaction.  Data such as taxonomy code and service provider location are not on the current 835 transaction, and these data elements have not been included in the 5010 version.  Since many payers will be requiring this additional data to uniquely recognize distinct subparts within a healthcare organization on a claim transaction, it follows that the remittance transaction that is returned should contain that same level of provider information.  While many claim scrubber vendors are able to re-associate the remittance to the claim since they retain the claim data, other HIS vendors create claims but do not store claim data on the system as part of their processing logic.  Without the additional provider information on the 835 transaction, these vendors are at risk of not being capable to provide function that was previously available with legacy identifiers.  For these vendors, the lack of this information prohibits the 835 transaction to be processed at the same level of granularity as the 837 was process and adjudicated.  Providers historically have been capable of processing claims and payments at the same level of granularity with legacy identifiers, and they need to continue with that capability going forward.  Siemens believes that adding this additional provider identifying information to the 835 remittance is needed to ensure data consistency between these two transactions.  However, until that can occur, Siemens, and likely other vendors, will need to fund additional development efforts to support this situation, in order to accommodate the data inconsistency and provide customers with the level of support previously available with legacy identifiers.  Based on experience with previous HIPAA implementations, we expect to uncover other issues as industry testing intensifies.

Testing industry wide is in its infancy stages.  In the remaining four months it is not feasible to expect trading partners to conduct and complete the necessary end-to-end testing in order to be generally available across all parties.  The industry has been preparing for the last 2 to 3 years to provide NPI support, and yet we are left with only four months to accomplish testing and implementation.  The end-to-end testing that needs to occur includes:

  • Coordination between trading partners on readiness and timelines
  • Setup and testing of the affected transactions
    • Setup/testing of 270/271 eligibility transactions
    • Setup/testing of the 837 transaction with the NPI
  • Payer processing of the 837 and return of 835 transactions with the NPI
  • Vendor/Clearinghouse/Provider processing of the 835 containing the NPI to determine accuracy of payment posting
  • Trading partners’ review of the entire process to ensure accuracy of the end-to-end process

Due to varying payer requirements, timeframes and support strategies, testing and implementation will need to done on a payer by payer basis, as it would be impossible to bring all payers up at the same time.  In addition, some payers are not providing for end-to-end testing.  They will switch to sending NPIs in production.  This means that some problems won’t be identified before the conversion.  The lack of payer test systems, and the need to test with control batches of production data in many cases, further complicates this process.

In summary, Siemens believes that the industry is not ready to move to the NPI on May 23rd, 2007.  As stated previously, the lack of a system and documentation for NPI dissemination, as well as the lack of communication between payers, providers and vendors to obtain this information from their trading partners is of concern.  In addition, the lack of testing that has been accomplished to date, given the various states of readiness across the industry as well as the inconsistency of information on the 837 and the 835 indicate a need to postpone the current implementation date of May 23rd, 2007.

Siemens’ recommendation is to extend the continuation of the dual use strategy for a minimum of 12 months after the availability of the NPPES data. This approach will provide additional time to address the issues raised in this hearing, and others that may surface when testing by the entire industry begins in earnest, to include:

  • Obtaining access to provider NPIs to build the necessary crosswalks.
  • Improving communication on transition strategies and testing timelines between all industry trading partners.
  • Normalizing the interpretation and implementation of the dual use strategy across the industry.
  • Engaging in end-to-end testing and identification of impacts for resolution.
  • Establishing the consistency of identifying a provider across all payers, so as to enable the ‘Provider to Payer to Payer’ model.
  • Resolving the data inconsistency between the 837 and the 835 (may require development on the part of some HIS vendors).

On behalf of Siemens and HIMSS AFEHCT, I want to express my gratitude for the opportunity to share with you our perspective on industry readiness for the use of the NPI.

About

Siemens Medical Solutions of Siemens AG with headquarters in Malvern, Pennsylvania and Erlangen, Germany, is one of the largest suppliers to the healthcare industry in the world. The company is known for bringing together innovative medical technologies, healthcare information systems, management consulting, and support services, to help customers achieve tangible, sustainable, clinical and financial outcomes. Siemens Medical employs approximately 31,000 people worldwide and operates in more than 120 countries. Within the United States, Siemens Medical employs approximately 13,000 people and provides medical imaging technologies, healthcare information systems, management consulting, and support services to nearly 12,000 healthcare providers.

HIMSS (Healthcare Information and Management Systems Society): HIMSS is the healthcare industry’s membership organization exclusively focused on providing leadership for the optimal use of healthcare information technology and management systems for the betterment of healthcare. Founded in 1961 with key offices in Chicago, Washington D.C., Ann Arbor and Belgium, HIMSS represents more than 20,000 individual members and over 300 member corporations that collectively represent organizations employing millions of people within the United States and abroad. HIMSS frames and leads healthcare public policy and industry practices through its advocacy, educational and professional development initiatives designed to promote information and management systems’ contributions to ensuring quality patient care.

The Financial Systems area represents HIMSS’ newest endeavor in the area of financial and administrative transactions health information technology. This area provides focused attention on the integration and interoperability of financial systems, business administrative systems, e-commerce, electronic services, and offers support for administrative simplification compliance. This initiative was spearheaded with the unification of HIMSS and the Association for Electronic Health Care Transactions (AFEHCT) in May, 2006. This unification combined the subject matter expertise of both financial and clinical systems to achieve the most effective voice and platform for influencing policies and procedures in electronic commerce, financial and business transactions in healthcare.  Today, the HIMSS AFEHCT Advisory Council leads the organization with financial and business administrative initiatives and provides direction for HIMSS advocacy efforts in these areas.

HIMSS Collaborations: CAQH’s Committee on Operating Rules for Information Exchange – CORE  

CORE logo

HIMSS is proud to be one of over 100 industry stakeholders – health plans, providers, vendors, CMS and other government agencies, associations, regional entities, standard-setting organizations, and other healthcare entities – who participate in CORE. CORE participants maintain eligibility and benefits data for more than 125 million commercially insured lives plus Medicare and Medicaid beneficiaries. A primary goal of the CORE rules is to simplify administrative data exchange and facilitate interoperability. For more information please see:
http://www.himss.org/ASP/topics_FocusDynamic.asp?faid=175

For more information on HIMSS, visit http://www.himss.org. For HIMSS Financial Services information, visit http://www.himss.org/ASP/topics_bis.asp.