Statement to

NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS

SUBCOMMITTEE ON STANDARDS AND SECURITY

Industry Perspective on Claims Attachments

March 3, 2004

Donald L. Bechtel
Current Chair of AFEHCT and Compliance and Privacy Officer for Healthcare Data Exchange, LLC  (HDX)
A wholly owned company of Siemens Medical Solutions Health Services Corporation

Mr. Chairman, and members of this committee, my name is Don Bechtel, Chair of AFEHCT.  AFEHCT’s mission is dedicated to the effective use of standards for the efficient exchange of health information in a secure and open architecture to promote better healthcare services, reduce costs, and improve patient care.  This testimony is a collective statement from our members about implementation of the Claim Attachment Standard.

It would not be fair to say that AFEHCT represents all vendors for providers and health plans.  But, we do represent many of the larger and more prominent organizations in the industry.  We conducted several meetings with our members and others in the industry to answer questions you asked us to review with you today.  The three questions were:

• What is the readiness of the vendor community to implement this standard?
• What are the issues we anticipate may impede successful implementation?  and
• What recommendations can we offer to help ensure a successful rollout of this next standard under HIPAA?

GENERAL REMARKS:

AFEHCT fully supports the standards under HIPAA, and we believe Claim Attachments will significantly improve the efficiency and timeliness of claims adjudication and payment.  We believe when this standard is integrated into provider and health plan systems, it will increase efficiency and improve the overall quality of the health information being exchanged.  However, having learned from the previous HIPAA Transactions, we realize that we have many unknown and untried processes and systems enhancements to implement before we can accomplish our objective.  

We believe that Claim Attachments was originally put in the second phase of implementation because of the foresight of those involved with the initial planning and development of the transaction standards.  Those individuals understood that the Claim Attachment would be complicated, would introduce various process changes, would increase our interoperability challenges, and would also require significant investment to develop solutions that will work consistently among all the affected trading partners in the health information infrastructure. 

The implementation planning we perform now should allow enough time to both understand and resolve the issues that are certain to be found, prior to imposing deadlines for completion.  Due to the complexity and the problems we experienced during the first round of HIPAA, AFEHCT strongly recommends that the industry establish a Project Plan to coordinate the validation and implementation schedule for all covered entities and key players, namely, the vendors.  We will elaborate on this proposition throughout our remarks.

Many of our AFEHCT members (e.g., IDX, NDC, SSI, Per Se, Siemens), and other associations we have worked with over the years (e.g., HBMA – Healthcare Billing Management Association), stand ready to help the industry discover and document the issues that may lay ahead.  We are committed to assist in the identification of resolutions to those problems, and to conduct a trial implementation with other interested members of the industry from each affected healthcare segment to complete this work.  We will elaborate on topic later in our remarks.

READINESS:

Some of our clearinghouse and vendor members have begun to make the necessary enhancements to implement the certain claim attachments for DME and Home Health forms; some have participated in small pilots with an earlier version of the standard.  Some have developed prototypes, which were demonstrated at the recent HIMSS Conference this past February.  And, the Georgia Hospital Association (GHA) is in the process of building support for a regional trial implementation in their state.  Most of this work is preliminary and has been relatively basic.  To our knowledge, none of it has attempted to do all of the various functions that will be needed to fully support for Claims Attachments.

In general, most vendors, payers, and providers have been fully occupied trying to complete their implementation of the first set of HIPAA transactions.  As is clearly understood from various recent forums, including testimony heard at the WEDI Hearings in Tampa this past January, as an industry, we still have a long way to go before the initial work is finished for the claim transactions.  Still more time may be needed to finish the remittance transactions.  The other transactions (i.e., eligibility, authorizations, and referrals) have seen little progress to date.  This remaining work will continue to distract and consume most of us until at least the end of the summer, maybe later.  Issuing the Claim Attachment NPRM before the end of summer or early fall, in our opinion, would be a mistake, since few parties will have time to react to it or provide comments.

It is fair to say that the vendor community is apprehensive about implementation of the claim attachment standard.  There is uncertainty about the potential problems that will be encountered, and a desire to have some level of industry study and education on this transaction before we begin to develop our solutions.

ISSUES / CONCERNS:

AFEHCT’s members believe this is going to be a complex transaction to implement, as there will be a number of problems or issues to address during the integration of this transaction into our applications and systems.  The following is a quick list of issues that we have begun to recognize from our preliminary work.

1. Workflows – There are many workflow issues to be considered.  When a request for additional information is received, what will happen?  Most likely, these transactions will be received by a facility’s billing application.  Some sort of decision mechanism will be required to determine what work needs to be performed and where.  This might be a manual or visual review of the request or an automated function.  As a result, some application or manual function will need to be started to acquire the requested information.  This may require routing tables to initiate work or jobs on other systems or in other departments, depending on the sophistication of the facility.  The responses will need to be captured and assembled into the appropriate message and EDI transactions to be returned to the requestor. 

   Of course, both the request and response transactions must be captured by the provider and maintained together with the claim and some status information to indicate whether the work was completed, or is still pending.  This information will need to be made available to the claims management application or a billing workstation, and so on. 

   These requests will not only require application logic, but databases will be needed to store the request and response status information together with the claim information, for audit trail purposes.  Additionally, providers and their billing departments will need to make procedure and policy changes to support these new workflows.

   The workflows just described would imply that there are interfaces between the financial and clinical systems; but generally these don’t exist today.  Additionally, different vendors often supply these systems.  As noted above, these systems might even be on different networks, at different locations, and sometimes with unrelated organizations due to outsourcing arrangements. 

   Developing these workflows and associated interfaces will be complicated, which may require additional standards.  As noted above, each vendor will need to agree to follow a protocol to handle such requests.  These interfaces may need to accommodate manual interfaces, as well as automated interfaces when automation is not practical or available.  Appropriate rules will need to be defined for handling each request type.  We believe that defining the workflows will be the most complicated aspect of implementing this standard.

2. Dataflows – Locating data within a health enterprise has potential problems.  In some cases, the required data will be contained within one system, while in other cases data will be located in multiple systems, especially where clinical and financial applications are operating on different machines using potentially different technology platforms.  Where both clinical and financial services could be outsourced, such as with Laboratories and/or Billing Services, this data may not even be within the same facility or organization. 

   Beyond the challenge of knowing where to find the data and how to get to it, there could be other problems.  For example, it will necessary to establish user and/or system access controls, and once the data store has been accessed we’ll need to know exactly what data to acquire and how.  To add to this complexity, each data storage system could be different, featuring different coding structures and different technologies.  This will require access routines, application program interfaces (API), or remote procedures calls (RPC) to be developed by each vendor to accommodate a somewhat ubiquitous approach to acquiring the data.

3. Healthcare Settings – There may be location specific issues that will have varying requirements depending on their organization type.  For example, large hospital environments, laboratories, radiology facilities, small provider practices, home health organizations, and billing services all need to be studied and understood.
4. Interoperability – New interfaces between financial and clinical systems will need to be established to conduct business functions that traditionally have never been automated.  Most interfaces between billing and clinical systems today are done manually.  Establishing and developing the standard protocols for these interfaces within the health enterprise will require additional collaboration among the vendor community. 
5. Coordinate with EHR (EMR) efforts – We believe that efforts to extract clinical data for billing purposes must parallel and support the efforts underway to codify clinical data for purposes of clinical workflow support, including clinical decision-support.
6. Standards – Standards need to be established within the enterprise and among the different vendor systems they use to operate their business.  Additionally, the industry will need to come to agreement on standard interpretations when mapping between LOINC and other clinical code sets and information standards that may be used within the various information systems used only in a clinical setting today.

   Also, the vendors are concerned about what reporting mechanisms will be used by a health plan to inform the provider about the status of an attachment when it is received.  Again, as with the claim, there are many possible mechanisms that can be used, though none are actually required.  Consequently, we can expect a variety of responses or no response at all.  Hopefully, we can avoid this problem with the claim attachment standard by providing specific instructions for how positive acknowledgements and error reporting should be done.

7. LOINC – Outside of clinical systems, this is not a widely implemented code set today.  Interfaces between this and other codes sets, such as SNOMED, will need to be defined in a way that includes documentation for consistent mapping between the two that will be used by all providers and health plans.  Many Health Information Systems must be modified to support this new code set where it is not currently used.
8. Identifiers – Another point (or distracter) to be considered; we now have a new provider identifier standard to implement that must be incorporated into our applications by the end of 2005.  This will require significant changes for the health plans and providers, which will ultimately distract them from working on other implementation issues that are further downstream. 
9. Minimum Necessary Considerations – Since the HL7 Message standard does not include any instruction regarding what data elements must be used with each claim attachment type, the health plans will need to define what they require in their companion guides.  This will begin to raise questions about what is appropriate information and what is not; and some industry agreement will need to be reached. 

   Additionally, this standard will experience similar issues to those experienced with claims in general.  A wide variety of requirements now exists for the same billed services because each health plan was allowed to define their requirements differently in their companion guides.  If this is not corrected, we can expect a repeat occurrence with claim attachments whereby a wide variety of required format types and attachment detail will be required with each health plan having their own unique requirements.  Certainly, this will not be efficient or effective and potentially negates the original intent of HIPAA legislation. AFEHCT believes this should be more carefully defined through an industry consensus process to avoid repeating our claim experience through another set of companion guides.  This consensus process should be done by the SDOs responsible for these standards.

10. Infrastructure Changes – These may be required by many systems that are not prepared to work with XML today, in order to receive and send the HL7 CDA message.  There are different levels of readiness among the vendor systems currently used regarding the use of XML. 

    Additionally, there is some thought that EHRs may be helpful in the implementation of Claim Attachments as well.  We’re not suggesting that this is a prerequisite, but it may be helpful and something to consider relative to the timing of when EHRs are implemented versus Claim Attachments.

11. Competing Solutions – Recently, there has been some discussion about employing a web-portal solution for claim attachments.  While this is a good idea for some settings, this may not be an appropriate solution for all settings.   This could introduce additional costs to small providers who would require scanners or other equipment.  It would also reduce the interoperability available with a standard transaction.    We believe this could become a distraction from those trying to implement the transaction standard. 

    One fear, is that this will become the only vehicle for some entities to submit or receive attachments, thus creating yet another situation like we’ve experienced with the eligibility transaction.  Eligibility is not realizing its full benefits because portal (DDE-like) solutions are being implemented in place of the 270/271 transactions.  While these solutions may be less expensive to implement and maintain for one trading partner, they defeat the opportunity to integrate these functions into the provider’s applications, which would eliminate manual intervention to capture the information for use within patient management systems.  

    Yes, browsers can be automated to capture this information, but too often these data screens are changed without notice, which in-turn creates other data capture problems, especially when multiple screens must be navigated based on data decisions from prior screen that are added, removed or modified.  It is situations like these where not all parties are fully supporting the standard that will prevent vendors from fully integrating these transactions into their applications.  On the other hand, when the standard transaction is used with its full richness of information required to perform the needed processing, these transactions will be fully integrated into the application’s business functions.

RECOMMENDATIONS:

1. AFEHCT recommends that the NPRM for Claim Attachments be issued soon, so the industry will begin to pay more attention to this next transaction under HIPAA.  However, we also believe that in timing the release of the NPRM, HHS should consider the work in progress and the industry should be allowed to finish their implementations of the remaining HIPAA transactions from the first round.  Namely, Remittance, Enrollment, Premium Payment, Eligibility, and Authorizations and Referrals.  Once these are completed, release the Claim Attachment NPRM.

   The NPRM should anticipate the development of an industry project plan and a timetable necessary to complete the work to develop, test, validate, and deploy the claim attachment transaction across the country.   In the meantime, those who are ready should consider being early adopters and participate in an early trial implementation that brings forward documented issues related to the standard and implementation guides for resolution by the appropriate SDOs.  This work could begin now.

2. AFEHCT recommends that the industry develop a project plan with a realistic timetable be established for the claim attachment, which should consider a number of aspects and allow time to:
   • Analyze the requirements.  Those who are ready can start now with the existing standards and draft Implementation Guides that are currently available.
     • When the NPRM and Final Rules are issued, the requirements will need to be re-validated.
   • Develop the application code to perform the work using a rapid prototype development model.
   • Validate the development work
   • Conduct a beta/trial implementation that would include:
     • Several vendors for both small and large providers and payers
     • One or more clearinghouses, billing services, and a number of payers and providers.
     • Possible funding, especially for the smaller providers and health plans.
     • Several areas of the country.
     • A focused scope of work to validate.
     • Real data in a production-like environment.
     • A primary purpose of validating the Standards (X12, HL7, and LOINC) and the Implementation Guides.
     • Requirements that come from existing standard and implementation guide documents.
     • Note: work to create such a beta trial implementation is already in progress involving AFEHCT, HL7, HIMSS, WEDI SNIP and others.
     • Report the findings from the trail implementation to NCVHS and provide status reports.
   • SDOs or CMS should respond to the documented finding:
     • Adjust the standards (as needed)
     • Adjust the Implementation Guides (as needed)
     • Changes should be adopted for use with the Final Rule.
   • Publish the Final Rules after responding to above documented findings and the standards or implementation guides have been adjusted if necessary.
     • The Final Rule would adopt the implementation timetable established by this overall industry project plan to complete the work.
   • Begin national implementation as defined by the industry project plan, with any necessary adjustments that may have been identified by the trial implementation project.
     • Consider a phased in approach by each industry segment and perhaps by each attachment type.
   • Obviously, the plan as presented here needs to be fully vetted and more carefully fleshed out, but we believe that a plan similar to this must be developed to avoid previous pitfalls.  The work should be done collaboratively by the industry, which would include vendors, providers, and health plans.  We believe this work would be best done collectively by organizations such as: WEDI, AMA, AHA, AFEHCT, CMS, and others that are interested.
3. AFEHCT recommends that the final rule should not be issued before industry comments and input can be provided from the beta/trial implementation project.  There must be time to document the issues, and resolve them before a final rule imposes implementation timeframes.  It would seem clear to most observers that the first round of HIPAA lacked sufficient industry planning for the deployment and implementation of the initial nine transaction standards.  Let us not repeat this same mistake.
4. AFEHCT recommends that NCVHS consider recommending a phased deployment of the Claim Attachment.  Starting first with the sequencing of industry segments, namely health plans, then clearinghouses, then providers.  Also, perhaps some sequencing with the attachment types would be helpful, starting with those that may be less complicated to complete.  Such sequencing considerations might follow as a recommendation from the proposed trial implementation. 
5. AFEHCT recommends that NCVHS consider defining a means to fund a pilot and trial implementation.  AFEHCT believes that the standard must be beta-tested in actual operating environments before being frozen in the final rule.  There are too many new and complicated issues for the rule to specify and implement this standard without practical experience.  It is automating what is manual in most environments.  It requires interfaces from many divergent provider systems.  We are concerned about payer-specific variability in the standard.  New infrastructure is needed, with new interoperability challenges.  Yet the potential ROI is high.  AFEHCT believes beta testing through a pilot and trial implementation will improve the standard, smooth its industry-wide implementation, and ensure that the industry more quickly realizes the benefits.  Participation is fundamentally a voluntary contribution, but full success of the project will require funding for its central design and management.

This would conclude our prepared comments.  I would welcome any questions that you might have and again AFEHCT thanks you for the opportunity to present our comments to the committee.