Testimony of Robert Davis for

The Quality Work Group of the NCVHS

September 14, 2004

Introduction:

I would like to thank the committee for this opportunity to testify about the available standards to support the reporting of the committee’s recommended data elements to measure and improve the quality of health care in this country.   Before I formally introduce myself I would like each of you to think about an idea of Data Centricity.  In my view the concept of data centricity is that decisions about what data is collected and how it are collected should be driven by the operational realities of our current data infrastructures in the health care industry.   I personally believe that today’s data infrastructures are increasingly becoming quite robust and can support more information needs than ever before. 

With that said my name is Bob Davis.   I am currently a health data standards consultant for the National Center for Health Statistics (NCHS), the National Association of Health Data Organizations (NAHDO), and the Agency for Health Care Research and Quality (AHRQ).    Formerly, I was responsible for the data collection of the New York State discharge data system, the Statewide Planning and Research Cooperative System (SPARCS).   For the past several years I have been very active at both X12 and HL7, Data Standards Maintenance Organizations under HIPAA.   I am also currently a voting member of the National Uniform Billing Committee representing the state perspective for Public Health Data Standards Consortium.

In my work with these various organizations, I have become the principal author of the Health Care Service Data Reporting Guide with input and assistance from experts across the nation.  This is an implementation guide, based on industry standards, written specifically for hospital public reporting using the ANSI ASC X12 837 standard.  Keepers of state discharge data systems have been the main contributors to this guide developing the business cases for the reporting data elements supported in this technical specifications document that go beyond paying a health care claim.   Discharge data agencies that maintain hospital discharge data generally fit into two categories;

1. Those mandated by state legislation to collect hospital discharge data
2. Those with no mandates that collect hospital data voluntarily.

For both mandated and voluntary systems the ubiquitous core data for state discharge systems is predominately the UB-92 and soon to be the UB-04.   I think the reason for this is clearly that the current hospital-based and clinic UB-based infrastructures are able to support these reporting requirements.   The Health Care Service Data Reporting Guide is maintained through the normal and routine change processes at X12 and the NUBC.  It is important to note that the Health Care Service Data Reporting guide supports additional data elements beyond what is included in the HIPAA mandated 837 professional, institutional, or dental claim implementation guides. Each of the 837 guides was developed for a specific business case; therefore the content in each varies.  For example, the 837 Institutional Guide was developed to include data elements necessary to pay a health care claim for services performed in an institutional setting.   The Health Care Service Data Reporting Guide identifies the data elements needed to create market, policy, and research information in state discharge, so it will include clinical and demographic data elements for that purpose.

The relationship between data sources and the data collection systems is in my view key to the successful mining of accurate and complete data from existing health services data infrastructures.  That relationship must be preserved at all costs. Again think data centricity.   

Body of Testimony

Now I will spend some time discussing the specifics for your recommendations and what is already supported in the Health Care Service Data Reporting Guide and how the Health Care Service Data Reporting Guide could be expanded to support other of the committee’s recommendations.  My discussion will focus predominately on the data elements necessary to carry out the committees recommendations.   The source of the data elements I am discussing is column 2 of the Summary Recommendations Matrix.  I understand I have been asked to discuss the only some of the committees  recommendations, but I feel compelled to comment on some of the other recommendations that are equally important and have a logical place in the existing standards and my testimony today.

Questions

Question 1 asks about the feasibility of collecting the recommended data elements.  

The following data elements are already supported using the Health Care Service Data Reporting Guide 837 implementation document.

• Discharge Diagnosis Modifier/Flag for “Present at admission” - note: this data element is not supported in HIPAA mandated 837 claim implementation guides, but is supported by the HCSDRG implementation of the 837. –This data is currently collected by the California, New York, and Wisconsin state discharge systems with more and more states expressing interest in adding this data element to their state discharge systems.  Three such states that have contacted me directly about the standards issues associated with adding this data element to their state discharge systems are Maine, New Jersey, and Virginia.  (This is Candidate Recommendation 3). 
• Data on Race & Ethnicity of patients - note: These data elements are not supported in HIPAA mandated 837 claim guides.  These data elements were added to the list of candidate recommendations I have been asked to testify about.  Because of their importance I would have made sure the committee knew that both are current supported by the HCSDRG.  This data is collected by most state discharge systems today.  The X12 and HL7 standards have both been modified recently to conform to the OMB Directive 15 Race and Ethnicity recommendations.  (This is Candidate Recommendation 12)
• Operating Physician Identifier Code - This is a data element supported by the institutional 837 implementation guide as well as the HCSDRG.  The issue with this data element is agreement on a satisfactory unambiguous definition, which is currently an action item for the NUBC and the X12N Claims work group. (This is Candidate Recommendation 4)
• BOTH Dates and Times for Admissions - These data elements are supported by the institutional 837 implementation guide as well as the HCSDRG.   Issues of data accuracy I believe would be self-resolving with increased use, as provided by quality measurement initiatives, would provide. (This is Candidate Recommendation 5)
• Episode start & end dates for services billed using Global Procedure Codes - This is a data element supported by the institutional 837 implementation guide as well as the HCSDRG.  Again, issues of data accuracy I believe would be self-resolving with increased use, as provided by quality measurement initiatives, would provide. (This is Candidate Recommendation 6)
• Standard Provider Identifier  - Note:  All 837 implementation guides, including the HCSDRG, currently support proprietary provider identifiers and are preparing to support the National Provider Id when it becomes effective in 2007.  This is not a data element that I have been asked to comment on, but I believe all the identifiers named in the HIPAA legislation are important pieces of the quality measurement puzzle.    (This is Candidate Recommendation 21)
• Voluntary Standard Patient Identifier/Identifier Logic  - Note:  This is a data element supported by the institutional 837 implementation guide as well as the HCSDRG.  Even though this is not one of the candidate recommendations I have been asked to comment on, it is too important for the success of an interoperable solution to not mention how it is supported in the standard.  Our health delivery systems today are very diverse.   Having a reliable linkage variable is an incredibly important piece of quality measurement puzzle necessary to provide us with robust interoperable and integrated systems. (This is Candidate Recommendation 22)

The following data elements are going to be supported in the next ANSI ASC X12n version (5010 – snapshot of the standard as of October 2003) of the Health Care Service Data Reporting Guide 837 implementation document.  Addition of these data elements requires no change to the X12 standards and involves minimal work to use the robust 837 standard to support these data elements in the Health Care Service Data Reporting Guide.

• Expanded Diagnosis Coding Standard - This change is also being made in the 837 Institutional, Professional, and Dental Claim implementation guides.  It is important too note that support for ICD-10-CM and ICD-10-PCS is “ready” for use in the 5010 version of X12 implementation guides because of the efforts of Michelle Williamson of NCHS and her work on behalf of the Public Health Data Standards Consortium. (This is Candidate Recommendation 16) 
• BOTH Dates and Times for Procedures – Note Procedure Dates are already supported in all 837 implementation guides.  The 5010 version of the HCSDRG is the only guide currently planning to add support for the procedure times at the current moment.  (This is Candidate Recommendation 5)

In keeping with my theme of Data Centricity, I believe the current administrative transactions and in particular the Health Care Service Data Reporting Guide implementation of the 837 is the appropriate transaction for collecting the data for statewide hospital discharge data systems in a cost effective and accurate manner.  This is not saying that improvements cannot be made in the collection and use of this information.   I am suggesting improving these systems is a better approach than re-inventing this wheel again. It has taken many years to establish trusted statewide reporting systems.  Once systems are established, expansions and enhancements are possible because of the reporting relationships and technical capacities that have been put in place.  Therefore, established systems can serve as a cost effective platform for data enhancements capable of delivering accurate data in a timely manner.  This is especially true as more and more state discharge systems, like New York and California to mention just two, embrace internet technology for their data transmission solution allowing for more timely data submission.

The following data elements could be supported using the Health Care Service Data Reporting Guide 837 implementation document because of the robustness of the ANSI ASC X12 837 standard.   Again, returning to my concept of data centricity, I am not sure if the administrative transaction would be the appropriate place for the collection certain clinical information to occur, even though it is possible to revise the Health Care Service Data Reporting Guide to provide this support.  Provider health information system capabilities really will determine the best method for collecting, storing, and transmitting this information. The recommended clinical information may indeed be better supported by use of an attachment transaction integrated with the appropriate administrative data.  For me there is no confusion that the data infrastructures are the horse and the appropriate transmission transactions are the cart to create a model where the horse is indeed before the cart. Again, I return to the concept of Data Centricity.  

• Selected Laboratory Test Results  -  This could be supported by the HCSDRG assuming appropriate LOINC codes exist for the desired information, which I believe is the case.  There already are ANSI ASC X12 qualifiers to use LOINC codes which could easily be added to an implementation of the 837 standard, but again I pose the question as to whether this is the best approach for collecting complete and accurate data.  The question that does not need to be asked is the value of this information.   NAHDO membership has been engaged in the issue of using administrative data for quality measurement, research and policy for several years and will again have this topic on the agenda of its annual meeting in DC on December 7^th and 8^th.  There is no question that current health service infrastructures store this information.  The challenge is how to integrate this data along with the other candidate recommendations into the reporting systems of the future. (This is Candidate Recommendation 1)
• Selected Vital Signs & Objective Data  - These data elements could also be supported by the HCSDRG again assuming appropriate LOINC codes exist for the desired information – As I mentioned earlier there already are ANSI ASC X12 qualifiers to use LOINC codes which could easily be added to an implementation of the 837 standard, but again I pose the question as to whether this is the best approach for collecting complete and accurate data.  At issue with these data elements is universally defining the vital signs to be collected.   For instance should we be collecting vital signs at time of admission, discharge, or sometime in between?    Whatever the decision, standardizing the definition will be critical for making maximum and effective use of this data. Collection of this data would most likely be more difficult because of the decisions that will need to be made on which data to report.   NAHDO membership, however, agrees that these data elements would be valuable for the purpose of quality measurements and that appropriate collection solutions are worth pursuing. (This is Candidate Recommendation 2)
• Primary Language of all enrollees - Note: this would require a change to the 837 standard  to include an additional segment (DMA), but no change would be necessary to the X12 standards.  This is yet another example of how robust the X12 standards are.  It is important to note that this data element is part of a measure set under consideration by the industry at time of admission for quality, disparities, and accountability purposes.   I believe the appropriate home for this data element would be along with other demographic information in administrative data systems. (This is Candidate Recommendation 13).  
• Functional Status - Note: an appropriate external code set would need to be defined within the X12 standards to provide support for this data in 837.  This would require a change to the X12 standards. Once a functional status external code set is known to the X12 standards, making a change to any of the 837 implementation guides, including the HCSDRG, would be easily accomplished.  Questions about defining what data should be reported and the best way to report it would remain, but the first step of supporting the need in the standard would be accomplished. (Candidate Recommendations 7 & 8).   

The following concepts listed in the Summary Recommendations Matrix would not apply to the data elements maintained in the Health Care Service Data Reporting Guide, but certainly enhance the quality and accuracy of the data that is supported.  I hope to be included in the future discussions the committee has on these recommendations.

• Adequate benchmarking data for states & metropolitan areas and racial & ethnic sub-populations
• Standard survey items
• Data on Race & Ethnicity of all enrollees
• Standard Clinical Terminologies
• Common Vocabulary for Patients
• Crosswalk of standard procedure codes across care settings
• Clinical Decision Support functionality in EHRs
• Standards for Data content and Reporting functionality in EHRs
• Interoperability of EHRs and standard formats for selected record extracts from EHRs
• Impediments to record access & linkage for coordination of care and QA/QI

In response to the question about benefits to your constituencies and the value added, it is important to note that over 45 states have invested in the collection and use of hospital administrative data and these systems have proven utility for market, policy, and quality purposes.  Variation in health care use, cost, and outcomes target populations or areas in which health care improvement activities can be detected.   Enhancements to the core administrative data elements will increase the utility and value of current data for surveillance, quality, and policy purposes.  Our challenge is figuring out how make the needed data improvements for quality and policy without significantly adding burden to an already overburdened health data infrastructure.  It is in everybody’s best interest to figure this out.

In response to the question about the burden of collecting this data and resource cost, it is important to note that because administrative data systems for state reporting are aligned with existing industry systems and transactions, the burden of reporting these data statewide is reduced. Again, think Data Centricity.  The cornerstone of the concept of the data-centric reporting is that our current systems are very robust; however, they are not integrated.  Integration of these data systems would solve the interoperability questions. As I understand and fully support, a goal of the EHR initiative is to promote interoperability within and across our health service data systems.  This would include interoperability between administrative and clinical systems.     Completely replacing existing administrative data systems with new clinical systems will create a significant burden for both collectors and users of the data, especially since replacement systems will likely need to replicate many of the functions of existing systems.   Adding additional clinical functionality to our administrative systems will also burden our current infrastructure.  This reminds me of the Goldilocks Principle – not too much, not too little, but just right. We need balance between our administrative and clinical systems with just the right amount of redundancy to enable the concepts of interoperability being proposed in the EHR initiatives.  I would like to you to think of a concept of transition – incremental convergence of administrative and clinical data systems.  For example,

NAHDO suggests data enhancements might be staged incrementally in three groups that reflect availability and reporting burden: 1) laboratory; 2) vital signs; and 3) clinical observations, with laboratory considered a likely starting place for enhancement of administrative data. According to experts in the health information industry:  

• many hospitals have electronic laboratory systems in place and this number can be expected to increase over the next few years
• LOINC standards for laboratory values are well-developed and widely understood
• Abstraction, if required, is relatively low cost

Vital signs and clinical observation data are also high value data elements, but these data elements are not widely available in electronic form and they are difficult to uniformly abstract. Business rules and definitions are not well-developed.

Research is available to begin development of the business case that lab (and clinical) data add predictive power and scientific validity to health care administrative data.

In response to the question about whether any of these data items would aid or hinder response to the growing interest in pay-for-performance, I must admit my expertise is figuring out how the standards can be used to support well defined business needs.   However, according to the NAHDO and the Consumer-Purchaser Disclosure Group, enhancing core UB-92 data elements by adding very specific target data elements, such as lab values, increases the power of existing administrative data significantly.  With lab values integrated with state discharge data, the capacity to track and monitor nosocomial infections, compare outcomes, and increase surveillance of chronic and acute conditions increases significantly.  Whether these data elements are the best ones to measure the quality of care should be left to someone else with more clinical expertise than me.

In response to the question about the usefulness of these data elements to add to quality improvement efforts, my personal expertise is again figuring out how the standards can be used to support well defined business needs.   However, NAHDO membership believes that the severity adjustment algorithms will become more predictive with the addition of specific clinical variables, thus benefiting pay for performance initiatives, hospital quality comparisons, and consumer choice activities.  In particular collecting the lab values could and should be the lowest hanging fruit for immediate pay back at minimal burden to the provider community.

In response to the question about how the candidate recommendation should be implemented to yield the maximum benefit, my only comment is that in a perfect world it would be beneficial to implement all of the recommendations in one integrated comprehensive fashion.  The realist in me, however, thinks that a prioritized incremental implementation is more likely to be successful.

In response to the question about the process for changing and/or modifying existing standards or developing new standards, I firmly believe in the consensus process.   Using that model for change, the burden of proof for changing and/or modifying existing standards or for the development of standards is always incumbent on the requestor of the change.   The requestor needs to convince the industry that there is a business need for change that cannot be met using existing standards and that these changes also benefit the industry by improving quality improvement, for instance.  Public health has a long history of reporting requirements without compliance, either because the data suppliers do not have the capacity to report, or reporting burden outweighs perceived or real benefit or incentives.   The question for all of us to answer is that the cost is less than the benefit to be gained by collecting new data.  If so, the change should be approved by the appropriate standards development organization.  If that is the case the reporting requirements would be tailored to the current capacities and linked to the common or public good.

Conclusion:

We are all aware that health care costs are rising.   They are the largest cost for many states and businesses, yet we know very little about how that money is spent and what it buys?  The quality of care issues are unfortunately pervasive enough that most people having recent contact with the health care delivery systems for themselves or a loved one will likely have their own “not so good” quality of care story to tell. 

The Health Care Service Data Reporting Guide is a vehicle for utilizing our existing health care data resources to help answer basic questions about quality and cost of health care in this country.   I believe using our existing health services infrastructures together with the help of modern technology to manage the integration of these diverse health service delivery systems will enable us to take a data centric approach to achieve our common goals.  I would like to thank the committee for allowing me this time to add my experience as food for thought as we all strive in our own ways to improve the quality of health care for the citizens of this country.