Hubert H. Humphrey Building
200 Independence Avenue, S.W.
Washington,
D.C.
TABLE OF CONTENTS
Page
Call to Order, Welcome and Introductions 1
Panel on Oversight, Management and Regulation of Health Care4
Panel on Electronic Health Care Transaction Transmissions 53
Panel on Software Vendors 114
HHS Survey Integration Plan 183
K2 Workgroup Discussion 219
P R O C E E D I N G S (9:16 a.m.)
DR. LUMPKIN: Good morning. My name is John Lumpkin and I'm chairing the Work Group on the Administrative Simplification, which is a work group of the Subcommittee on Health Data Needs, Standards and Security of the National Committee on Vital and Health Statistics.
We're going to start off with introductions and we will perhaps start at the table.
DR. COHN: I'm Dr. Simon Cohn. I'm a member of the committee and also a member of the subcommittee and work group. I am the Clinical Information System Coordinator for Kaiser Permanente and involved with CPRI and ANSI HISB. DR. JANES: Gail Janes, CDC, staff to the subcommittee.
MS. GREENBERG: I'm Marjorie Greenberg, National Center for Health Statistics, CDC and I'm the Acting Executive Secretary for the committee.
DR. BRAITHWAITE: I'm Bill Braithwaite, I'm staff to this working group here at HHS and the Office of the Assistant Secretary for Planning and Evaluation.
MR. SCANLON: I'm Jim Scanlon with the Data Policy Office here at HHS and I'm the Executive Staff Director for the National Committee.
DR. IEZZONI: I'm Lisa Iezzoni. I'm in the Division of General Medicine and Primary Care at Beth Israel Deaconess Medical Center in Boston.
DR. LUMPKIN: Great. Now we will move to the audience.
[Audience introductions.]
DR. LUMPKIN: I'm sorry, we're just establishing a quorum.
MS. GREENBERG: You have a quorum of the work group, you have three people.
DR. LUMPKIN: Okay, great.
DR, IEZZONI: Kathy is here, she was here. Her body is somewhere.
DR. LUMPKIN: Okay, so we're going to begin. And there she is. Now we have a quorum for sure.
Good morning. As I'm sure everyone is aware, we are operating under some fairly tight time frames to address the issues related to administrative simplification as passed under the Kennedy-Kassebaum legislation, which some of us around the table refer to fondly as K2, primarily because it's like K2, it's not the highest mountain we may have to climb in our life, but it sure is up there.
Many of the issues that are related to this legislation get to the heart of how we transmit and transfer information and data in the health care setting. It is in my mind, and certainly one of the issues that we will address as a work group in a subcommittee, that we need to not only look at the issue of standards, which is a key component in the charge to begin to look at those transaction standards, but it is also my personal concern that we continue to keep in mind that the purpose of this is administrative simplification, and that we can set standards which will not simplify. The goal of this is to allow practitioners and providers of care to spend as little time as necessary with the business of providing care and more time with the care provision component, which is why this system is in place.
So, as we go forth, certainly I would appreciate the comments related to the issue of standards, how standards impact your particular organization and also what you think would be the needs for administrative simplification. We're also concerned about the issue of variability, because we think those too have some impact, how much variability should be allowed. We all know that the HCFA 1500 form has provided or was attempted to provide a certain amount of simplification. The only thing is we couldn't figure out which one to use, so every particular entity used their own separate form and that has I think not helped the situation. So we're trying to struggle with the issue not only of whether or not we should have standards but how much variability within those standards are necessary and would have an impact on the various users of the data that come out, what really is necessary, how uniform can we get at the site of the delivery of care.
So with those opening comments, do we have any others from the members of the panel?
Our first panel today is on Oversight, Management and Regulation of Health Care. We have one additional speaker to the panel and that's Dr. Al Buck from the Joint Commission. Why don't we start off with, we will go from my left to right, we will start out with Al.
DR. BUCK: Thank you, Mr. Chairman, ladies and gentlemen. In the verbal part, first let me say I've distributed a written statement for the committee and attendees. In the verbal part, I want to address the first and third questions that were in the fax distribution. The first is what does your organization expect on behalf of the work of this committee and focus on the Kassebaum-Kennedy bill.
The first I think on behalf of the Joint Commission, which I think most know is the country's largest accrediting body, we expect, hope that we will see improved processing and transmission of data and information related to health care. A second expectation is an impetus for dynamic process refinement of a standard data set and we've all seen some major steps and progress in that regard. The third is the facilitation of integration of data from various domains, specifically cost, administrative factors and clinical outcomes.
Now, in assessing the Kassebaum-Kennedy bill, and anticipating we think a necessary addition provided in the form of confidentiality legislation, we're looking to specifically see some bridging, I guess would be the best way to put it, and some focus on some issues that we think as an accrediting body are not completely addressed or comprehensively addressed as yet well enough in the existing Kassebaum-Kennedy legislation. Therefore I would focus on four concerns or recommendations which gets to the third question that was on the sheet that was distributed. I will just briefly summarize this and later on welcome question and discussion.
The first recommendation is that national accrediting entities when appropriate should be referenced as standard setting organizations. The Joint Commission has been a pioneer in the development and promulgation of consensus based national standards for health care and related services, including services that relate to the use of data by health care organizations. These are standards that are widely distributed, widely known, widely utilized. If there is interest, I would be happy to provide a copy of those standards to the committee or attendees. Those primarily are in the chapters and the accreditation manuals of which there are seven, in chapters entitled the Improvement of Organizational Performance and Information Management.
In passing, also I would say to get more specific even, that these standards are applicable for adverse clinical events, patient and provider satisfaction, utilization of resources, financial performance and so on.
A second recommendation focused on a concern is that clinically oriented data elements, whether individually identifiable or in aggregate, need we think more comprehensive treatment in legislation and oversight activities to facilitate integration as appropriate with financial and administrative data elements.
I would make this comment. Aggregate data, not specifically identifiable back to an individual is and will be sufficient to support the performance assessment needs of accreditation activities in most circumstances. However, in certain circumstances, such as the evaluation of a sentinel event occurring at an accredited provider organization, and I would also add in those other circumstances where we must go backwards from aggregate data to patient level data, in those two circumstances, we believe that patient specific and patient identifiable data are necessary to round out the oversight required by accreditation activities.
A third recommendation is that external comparative metrics that provide high level organization comparison should be stringently defined. Disclosure of these metrics should not produce a risk for discoverability of other data or data based content on the part of the health care organization. I would suggest that if there's interest or perceived need in this regard that a task force of national accrediting bodies might serve the subcommittee well in addressing this extremely significant but contentious report card issue. Increasing need for statistically meaningful data audit standards and processes is mentioned above in the written statement, whether to verify aggregate data or perhaps in some cases to investigate potential fraud or other unlawful activities. There must be a structured protected process to go backwards from aggregate data.
A fourth recommendation is that national accrediting entities should be included in the definition of data clearinghouse if that concept and term are carried over from P.L. 104-191. A better designation we feel, however, would be that national accrediting bodies would be designated either in clarification or new legislation as health care quality oversight organizations, in other words, to establish and recognize and utilize that term if it's thought better to shade the grey difference between that and the current term expressed and defined in the existing legislation of health care oversight organization.
In closing, I want to say to the committee and attendees, the Joint Commission strongly endorses the subcommittee's charter. We invite further discussion in any area of concern, and we have a substantial number of documents, including existing accreditation manuals that we would be happy to provide should the situation be assisted by that. Later, I would certainly welcome questions and discussion. Thank you very much.
DR. LUMPKIN: Thank you. Mr. Tierney from NCQA.
MR. TIERNEY: Thank you. Good morning. I would like to thank the committee for giving NCQA the opportunity to discuss what we believe are the implications of the administrative simplification requirements and what they will have on our work. NCQA is a not-for-profit organization committed to evaluating and publicly reporting the quality of managed care plans. The Health Employer Data Information Set, or HEDIS as it's referred to, in combination with information from NCQA's accreditation program, provide a comprehensive view of health plan quality aimed to guide choice among competing health plans.
Over the last 18 months, NCQA and its Committee on Performance Measurement has led the nation's efforts to develop a richer more extensive set of measurement standards to evaluate the quality of care and service provided by managed care plans. The product of this work, HEDIS 3.0, significantly extends the state of the art and substantially increases the public's availability to compare the quality of managed care organizations.
Yet those who created HEDIS 3.0 recognize that there are real barriers to progress. Each new version of HEDIS creates tremendous burden on managed care organizations because they are unable to easily implement new performance measures. Today's environment presents the managed care industry with significant challenges when measuring health care quality.
There are few health plans in this country that are satisfied with the extent and quality of clinical information in its databases. This deficiency has an effect on the quality and effectiveness of performance measurement. Health plan information systems fall short in several categories. Data elements are not captured, standardization is limited to a few elements in a few records, data quality is highly variable and rarely measured and linkages to internal and external data are rare.
Health plan information systems draw clinical data elements primarily from claims. Definitions, content and coding of the information are based on the requirements of the claim adjudication process. In many cases, payment arrangements such as capitation eliminate the requirements to submit even basic claims data. Even if the claims are submitted on all medical services and all claims data are entered into the health plan's system, these databases lack most performance measurement data. Today, performance measurement draws on claims databases because they are available not because they are ideal.
Automated linkages of data in separate systems within the health plan and among its contracted providers do not exist or are difficult to implement. It is common for a health plan to use separate software packages to satisfy different requirements within the organization. Combining data across these applications is often difficult and costly. Providers under contract to the health plans may have systems with extensive data that could be used for performance measurement. Unfortunately, most health plans do not have the system capacity to integrate these data with their own internal databases.
The lack of these linkages increases the need for manual data collection for performance measurement. Medical chart audits are conducted to obtain data that might exist in systems outside the walls of a health plan. We have found that automated data used for performance measurement have significant data quality problems. NCQA's HEDIS audits comparing administrative performance measurement data with medical records have found denominator errors over 60 percent in some cases and numerator error rates over 70 percent. It is not uncommon to find situations where claims do not accurately reflect the majority of the clinical important patient conditions. These factors highlight the impact of data quality on the validity and reliability of performance measurement derived from administrative databases.
The information demands for performance measurement require not just information systems but an information framework, an idea that goes beyond the more narrow concept of hardware, software and data. The framework includes not only these components, but also the specifications of types of information and data elements and specifications to permit the linking of information systems and the data within them.
To address this issue, NCQA has commissioned an Information Systems Work Group for HEDIS 3.0. The charge is to develop a road map that will communicate directly to the managed care industry what upgrades and information systems would provide the greatest increase in performance measurement capacity and thereby accelerate the creation of an environment in which advanced performance measures could be implemented.
Many forces have converged to create the current information systems environment. The situation does not represent a failure, but is the natural outgrowth of an industry experiencing rapid change in a field as complex as health care. Incremental improvements are required to increase the industry's capacity to measure and improve performance. There is an opportunity to make significant advances in health plans, if health plans, providers, purchasers and government agencies can collaborate to overcome the current constraints.
It is our hope that the administrative simplification requirements move the managed care industry forward towards standardization in the structure, content, definition, coding and transfer of clinical data. As this occurs, the managed care industry will be able to meet the future demands of performance measurement. We certainly support the development and mandate of standards for patient and provider identifiers, record structure, codes and messages to support more comprehensive clinical management and performance measurement. We also believe it is important to develop and implement appropriate quality control mechanisms to ensure consistent interpretation of these standards. Only the will we be able to significantly expand our capacity to measure the quality performance of health plans in their service units. Thank you very much.
DR. LUMPKIN: Thank you. Randy Desonia.
MR. DESONIA: Good morning. Thank you for inviting me to present before your meeting on the administrative simplification provisions of the Kassebaum-Kennedy Act. As the responsibility for programmatic decision making continues to devolve to states, there is a need for more timely, focused data and information on the health care activities within the state's borders. This act can help governors significantly, both as major health care purchasers like Medicaid and other health programs, but also as health care regulators.
Before I make my brief remarks, however, I want to explain who I am and what my responsibilities are at the National Governors Association. I'm the Director of the Health Division with the NGA's Center for Best Practices, a 501(c)3 entity that provides technical assistance to governors, their staff and key state agency policy makers. It is important to note that my remarks do not constitute official NGA policy, nor do they represent the perspective of any particular governor or their staff. Instead, my remarks represent the perspective of an individual who has worked with states on health policy, programmatic and data issues over the years. I believe that this experience enables me to provide some options that may be of value to the subcommittee in its future deliberations.
In particular, while the technical nature of your work requires detailed input on such intricate issues such as computer technology, definition of data elements and patient confidentiality. I'm here to remind you that there are some larger trends to keep in mind when developing your recommendations. After all, we are finally entering the information age.
First of all, there is a lot of devolution of programmatic decision making to states. As the federal government provides greater flexibility to states in administering state federal programs, including the recent Welfare Reform Act, states are becoming more interested in obtaining information that is state specific in order to better inform state policy makers and better assist program managers in monitoring their program so that it can be made more effective. No longer is it acceptable for states to simply use national figures when looking at state health issues.
For example, with funding under Robert Wood Johnson Foundation State Initiatives in Health Care Reform, my unit is collaborating with Rand in helping a set of states develop alternative methodologies to estimate the health expenditures within their states. Obviously the information on providers can assist states in improving the effectiveness of these state health expenditure accounts as well as the Medicaid programs and other health programs, particularly if the information is timely and specific.
I also want to encourage you to learn from the experiences in some states that have considered similar electronic data exchange efforts such as the state of New York. I think that some common issues probably arise and we might as well learn from them right away.
A second trend is towards performance outcome measurement systems. Just like the government Performance Results Act, which instructs federal agencies to develop systems to measure the effectiveness of a program by focusing on the outputs and not just the inputs, states are interested in developing outcomes based systems such as the Oregon Benchmarks and the Minnesota Milestones efforts, and they're moving towards performance outcomes under Medicaid, particularly with managed care and some other health programs.
This trend has caused states to fundamentally reconsider how to transform the current categorical data sets into an information system that can aggregately measure a program's effect on the client. The promise of EDT is to provide more informative and detailed data to states in a less costly format.
The third trend is state agency restructuring. Several states are fundamentally changing the way in which agencies are organized. Major consolidations are becoming common in the health and welfare agencies, and one of the trends is also to restructure agencies on a more functional line basis so that a lot of data and information systems that used to be scattered through different agencies are now being consolidated into one major agency.
This trend has highlighted the fact that there are numerous data systems that are so fragmented and categorical that they provide no useful information for decision making even when they are serving the same populations. States are developing strategies on how to best select the right amount and type of data and how to make the best investments in computer technology so that the resulting managerial system is responsive and cost effective.
The excellent questions listed in the invitation letter to me are too complex to address at this time. Therefore, in your coming deliberations, I encourage you to work with governors and their staff in developing your recommendations. While the intricate nature of your charge requires you to work with such state based policy makers as Medicaid directors and insurance commissioners, please remember that there's a cross agency policy and information investment perspective that only the governors can provide. I can state with certainty that NGA would welcome the opportunity to facilitate such an interactive process between your work and states efforts.
Never in my 19 years as a policy analyst in state based health issues have I see such gubernatorial demand for better information systems. They are very active in transforming their state agencies to be more information based and already implementation plans are being developed. I believe this presents a wonderful opportunity for state and federal government to work together in making agencies more efficient and effective. Thank you for allowing me to make these comments.
DR. LUMPKIN: Thank you.
MR. MEROLD: Thank you as well for including IMS in today's discussions. The challenge going forth is to try to say something that hasn't been said before. Particularly given our ongoing dialogues with NCQA and the Joint Commission, I would just simply echo a lot of what they have said and something that IMS would heartily endorse.
For those of you who don't know us, even though most of you are customers of us, or at least your agencies are, IMS is the largest health information company in the world. Our business is about collecting health care information and turning it into information databases that can be used primarily in the efficiency and effectiveness of health care. We operate in 83 countries around the globe. In the U.S. we collect every month 72 billion, with a B, records from over 100,000 data sources, which last time I checked is probably over 200,000 data sources, and every month we deliver to our client base over a terabyte of data on the health care marketplace.
Our business primarily has been oriented around the tracking of pharmaceutical products to their points of distribution, to the prescription activity of individual prescribers and how they use pharmaceutical products. More recently, we've been taking an active role in patient centered information that we have 30 years of experience doing this on a manual panel basis. With the computerization of doctors offices, collecting records from primary care physicians, collecting claims based information is a growing part of our business.
I will make one caveat here, I know this is not the privacy hearings, but IMS has extensive experience in protecting privacy. We operate under the EU guidelines in those seven European countries collecting this information. We follow the same practices here in the United States. We have experience with encryption technology, with maintaining fire walls. All of the data that IMS collects today is anonymized to protect patient privacy so we never get an individually identifiable piece of information, yet we're able to provide much value in the way of looking at outcomes and best practices.
The data that IMS and companies like us create has a significant role in both the oversight and management. For example, our data is used in the adjudication of rebates between the states and the pharmaceutical manufacturers. One of the things we found is that 40 percent of the problems that arise are simply a result of data editing errors. It's the quality and absence of standards in many cases that's contributing significant time and waste as manufacturers and the states try to reconcile very different pieces of data.
However, I would like to also ask that we take a more broad view of health care. It's not simply about cost, it's also about at the end result of patient care. One of the major areas is just in the subject of patient compliance and people taking medications that they should take to avoid more serious and more expensive health care problems later on. Our information would show that approximately, for a popular drug that's used for a chronic care condition, only two-thirds of the prescriptions that are ever recommended by the doctors are taken or taken in the right piece of time. That failure of the one third that's not taken is obviously leading to significant more emergency rooms and more serious conditions.
So using information to identify how to improve patient compliance, how to identify areas where compliance can be enhanced is another significant application, as is the whole subject of best practices in medical policies to determine which of many different treatment alternatives results in the best long-term patient outcomes and obviously optimizes the cost to the health care system.
Having said that, standards play an absolutely essential part in our business and in the promotion of more effective and efficient health care. To the question that was specifically asked at the start about variability, we find variability is the single biggest headache we have in pushing the information to its optimal end. When we can't identify data elements and what really was happening underneath by what is collected or coded, it significantly dilutes the value of the way the information can be used. I would echo what the NCQA said a few minutes ago about the real challenges in terms of data quality and promoting standards.
To that same end, accelerating the rate of standards is going to be increasingly significant. This is a very changing field. People are having enough time just running to stay in place. We need an organization like this that can set the bar for us in terms of where we're headed. In that context, of course, making extensive use of what's already available and happening in the private sector is essential. The one thing our experiences would tell us very emphatically is if the information that's being used is not a regular part of the practice of medicine, the quality of those data fields is going to be so sufficiently diversified and diluted and filled with errors that the return of those standards becomes significantly less.
Lastly, I would like to emphasize what the Joint Commission talked about in terms of the collection of clinical information as well as just the administrative information, because in many ways until you have certain clinical elements, it's virtually impossible to draw some of the conclusions that you would like to draw. I will give you one example to conclude which is that for a popular disease state, one of the five most common ailments afflicting Americans. There are three primary forms of treatment for an out-patient basis. Of those three primary treatments, our information would say that one of the three results in a threefold likelihood that the patient will wind up in the emergency room. This obviously has significant ramifications.
Our hesitancy in making this information more broadly available is simply that we lack some of the quality clinical elements to be able to discriminate whether or not some of the variability in the outcomes is due to patient factors, severity of conditions, as opposed to simply the fact that some treatments may be more effective than others. So again, we would heartily endorse the addition of clinical information and we thank you for having us today.
DR. LUMPKIN: Thank you. Questions from the panel.
DR. IEZZONI: Can I just thank the panel for their interesting comments this morning. Talking about adding clinical data to data sets is music to my ears, but it's not exactly what we're talking about at this moment. Perhaps Dr. Lumpkin could summarize again what exactly we're talking about standardizing in these exact hearings. My impression was that at this point we're not talking about as much adding clinical data or standardizing clinical data elements as we are the routine kind of data elements that are included in billing and enrollment types of data sets. If my assumption is reasonable, but you all who use these data to try to draw inferences nonetheless about the things that are of concern to you, such as quality of care, to what extent would you advocate adding one or two or three or five or 10 maybe little clinical data elements, just small clinical data elements to some of these code sets, maybe one or two? To what extent would this be something that you would feel is justified given the importance of the information in light of what Dr. Lumpkin raised at the beginning which was our goal of simplification?
DR. LUMPKIN: Let me perhaps clarify. I think that one of the components that were listed as the items in the first phase of K2 is attachments. Those attachments generally are fairly broadly interpreted to mean clinical information. So to the extent that we may have recommendations for standards in that area, this kind of discussion is germane.
DR. BUCK: I would sort of like to respond to that and pick up on it. Reading both the bill itself and the section C or the administrative simplification piece, it seems to me that there's a theme here of emphasis on very technical data element level technical standards, X12, HL7 a good example. I'm concerned about that in this bill, because in point of fact, the claims form and the attachments that you mentioned make a focus in my opinion, make a focus on billing or financial material and brief demographic stuff very deceptive. I personally believe that the claims forms are a very important hook, link to clinical data in that the emphasis on the bill is perhaps a little too much on the data element that relates to financial transaction. It concerns me a lot, because I think in the long run, a separation of that kind is neither real in terms of what's really on the form generated, or constructive in the long run in addressing some of the larger needs.
The other comment I would make is that in point of fact, and I will give you one example, HL7. HL7 is really very silent, and for the group here, the Joint Commission and I'm sure others here have worked with these groups personally on an ongoing basis to mature the X12 and HL7 and other ANSI standard setting bodies. But in point of fact, just as an example, HL7 2.3 is basically silent on data security and confidentiality. And I'm sure we could get into that more into the weeds.
I think there are three distinct levels here in my thinking about this. One is a data element technical piece, which I think is well addressed and we totally support from X12 and HL7 and that kind of thing. There's an intermediary level, if you will, which in my view is addressed not exclusively, but partly and significantly by accrediting agencies. If people have any interest in this, again I will be happy to share standards from our organization that address data quality and risk adjustment and audit criteria and so on, all those things that kind of weigh in at the organizational and multi-organizational level.
Then there's still another level and that's the national framework, if you will, which I think is not addressed in the Kennedy-Kassebaum bill, as positive and forward a step as that is. I'm talking here about the double sided coin of confidentiality on the one side and discoverability on the other.
So I think to me anyway, there are distinct levels of application here that I would hope the committee would consider completely and comprehensively. So what I guess is a long winded statement, that I think we really are on target here, even though it may not be directly visible.
MR. MEROLD: I would just echo with Dr. Buck. We've evaluated probably over 30 million patient elements I guess is the way to say it, patient lives and claims data. In our case, they're all anonymized, so there's no privacy issue, and I think privacy can be handled in this context. I can tell you there are certainly issues of correct billing, wasted billing that are not insignificant. That's not our business, so I won't really comment on it. But in looking at the broader applications of the data, and we all know where the real opportunities for efficiency are in the health care system, and at the same time better quality which is an important added factor, the claims information as it is being collected today is just simply inadequate for 95 percent of the applications.
DR. LUMPKIN: Other questions?
DR. COHN: Yes. First of all, I want to thank all the panelists for joining us. I will apologize I'm from California and I'm just waking up with the time change.
I do observe a number of people at the table represent people involved with performance measurements, I think a very vital and important activity. Yet, it caused me to think a little bit as we were talking about administrative simplification about the fact that we are seeing a huge proliferation of various performance measures which may as we begin to standardize and normalize data and administrative simplification may confound us and confound simplicity in health care and administrative costs by requiring more and more chart reviews and all of this.
I guess I would ask the members if you have any strategies and thoughts as we simplify both I guess the data elements in the administrative transaction sets and others, whether there might be a similar movement towards perhaps simplification or standardization of performance measures and is that an area that you think deserves some focus or thoughts by the committee?
DR. BUCK: Well, let me lead off. I'm sure the others want to comment as well. In the first place, two parts to my response. One is that I'm concerned, I'm for simplification, yet, but I think that it is clear that the potential, the necessity of having a very comprehensive uniform and implemented set of core -- and I avoid the word core, I've been sensitized by the committee, I won't say core data set, I will say standard data set -- but whatever is politically viable, I'm talking about a very dynamic, consensus based, refined, timely, updated set of elements that constitute the claims data, because I think the de facto standard, if you will, for the country today is the UB92 and the HCFA 1500.
Is that sufficient to build the kind of assessment system that we think we need to see in this country? And my opinion would be no. It is not sufficient in that it doesn't provide the diversity of data elements that are necessary for instance to do things like, in my opinion anyway, to do the kind of risk adjustment that we really should be doing in certain areas.
What is not known, and I would welcome comment, because I know Lisa is an international expert on this, but I believe that the issue really is the balance of elements that can be constructed from an optical read on a front sheet in those that do justify hands on and all the costs associated with hands on chart abstraction. I don't think anybody yet has the answer to say what the balance is there and what justifies the cost. Do we need that component? I think we do, even though we haven't yet defined how much we need it.
Lastly, in terms of consensus, I go around the country and I speak to very diverse audiences a lot. My plea always is to build consensus process for exactly the problem you described and some of the rationale you implied. We, again, I think enormous steps have been made in a positive direction here. I cite our organization, I cite NCQA, I cite FACT, I cite many of the regionalized data projects around the country, either at the state level or the multistate level.
There's a lot of good things going on, but we again in this area haven't a wrap on this in my opinion. We have not yet defined the, let's say the best consensus process to settle on a set of performance measures. We have a long way to go in this area, but I'm optimistic. I agree that you put your finger on a real problem and I'm optimistic about it and welcome other comments too.
MR. TIERNEY: I would like to comment a little. I think the work of this committee is the beginning steps to where we want to go in performance measurement. To the extent that we can standardize some of the data elements that are being received by health plans and providers of care allows us to do some of the things we're unable to do now.
One of the reasons why performance measurement is so burdensome for health plans now is because we lack the data elements we need to do the appropriate types of measurement that we would like to do. I think there is standardization that is an issue, it's capturing the data elements that are necessary to do that type of performance measurement.
At the end of the day, I would echo want Dr. Buck has said, capturing financial data on some type of care isn't what we're really after. If we're not able to identify the diabetics in our population, then I think that we're missing the boat. We need to be able to capture the information and automatically be able to look at the different types of chronic care and acute care illnesses that are represented in the health plan and be able to put the intervention programs in place. We're going to only be able to do that if we upgrade our information systems and build this information framework that I referred to.
So I think to the extent we have to be, as standard organizations, we have to be aware that there are a lot of activity going on in that industry and we have to be aware that we want to try to standardize measurement where it's appropriate. At the same time, in order to do that, I think it's automating and doing the work that you're doing here and extending that to the extent that we are dealing with clinical data, that's when we will start to see the issues that you're raising, the burdens for the health plan start to be minimized.
MR. DESONIA: I would encourage you to sort of take this as an evolving issue as opposed to trying to solve it all at once. Historically, when you're looking at developments of data sets, the George(?) experiences in Michigan and other vital statistics registrars show that if you try to get all the information that everybody would possibly want to have, you end up with a very cumbersome, expensive data set that no one can use because there's not enough money left over to do the analytical work and to take that data and put it into information.
So, it is something that you just have to be careful about this, sort of a sequencing that you might want to be presenting. For example, we're hearing at different meetings CDC is thinking about perhaps changing their Healthy People 2000 to be a bit more focused. The state of Oregon in its benchmarks program is reassessing it's specific indicators to see which ones are really the most powerful and we can use and maybe do away with some of the other ones. But as Dr. Buck mentioned, it's a delicate balancing act that you're going to have to address.
MR. MEROLD: And the other perspective on that is there are a few 800 pound gorillas out there who aren't waiting for national standards. You know in California Calpers(?) and other institutions and purchasers are already starting to generate their own standards and they're using their market leverage to start to dictate what elements are being collected and how. I think the last comment was appropriate that there's a lot being collected because someone wants it collected, but it may not necessarily be the best solution or practical. I think again, this is where a national standard could help cut through some of the market fragmentation that's now occurring.
DR. LUMPKIN: Let me perhaps ask a couple of questions here because I think there are some issues that I'm not exactly clear on in the comments. First, with the Joint Commission, let's say I'm a hospital and I'm going to be being reviewed based upon some of our performance, do we submit raw data to the Joint Commission and they do the analysis or are the rates calculated at the hospital and submitted?
DR. BUCK: Right now, there are two ways to go about this. One is implemented, the others are in development. The implemented program for voluntary participation, not required yet, but voluntary participation in a system where the hospital develops the data themselves, some of it requires hands on chart abstraction, some of it is the kind of thing you would see on a UB92. That data is processed through a central data managing source and then is provided to us through electronic filtering and various analysis where we do logistic regression to calculate risk adjustment when necessary or desirable in our opinion. Then we turn it around and provide to the specific organization a statistically sound analysis of certain selected measures that we have developed that touch on probably 80 or 90 even percent of certainly acute care, and probably half of chronic care. This is the so-called IM system and it's functional, it's implemented and it's producing statistically sound reports.
An alternate model which is being developed at the present time would allow us to take such similar data, but patient level originated, aggregated by another system, not ours, but transfer it to us so that we can compare those results against our own you might say risk adjusted model. We will also offer our risk adjusted model to the other performance measurement systems.
Again, I would say that in my view, this is the most meaningful assessment and reporting mechanism that I know of at the present time in the country. I would not present it as the last word at all. I think this is an evolutionary process.
DR. LUMPKIN: Therefore, when you get that data, do you prescribe the form? You prescribe the content, clinical information you want. Do you prescribe the form or is the burden of conversion to a standard form at the provider level or this intermediary that you're talking about?
DR. BUCK: Well, the technical standards in terms of data element definitions, coding, inclusion criteria, all that kind of thing have been developed laboriously over the past eight years and are in the public domain. It's all published and we have, I think the count is about 30 vendors that have software for this, but it's in that order of magnitude.
DR. LUMPKIN: And are those standards in conflict or comparable with some of the standards that have been discussed in front of this committee such as the X12N?
DR. BUCK: They are compatible. They are very basic, nonproprietary public domain standard data transmission standards.
DR. LUMPKIN: So in your business processes, adoptions of standards such as would be under the first phase of Kennedy-Kassebaum for transaction standards would not cause a problem for the way that you do business, except for the issues that you raised of loss of clinical content?
DR. BUCK: Yes, at the basic level, to the best of my knowledge, that's a true statement. Certainly that has been our intent. We completely support the efforts of the technical data standards efforts going on.
DR. LUMPKIN: Mr. Tierney, can you walk me through that same series? Does the NCQA get individual record level data from plans?
MR. TIERNEY: We do in some cases. For the most part, the plans are responsible for looking at that patient level data and aggregating that up to a rate. There are some measures, the functional status measure where patient level information is required. We also have, the way the measures are brought to maturity is we have a testing set of measures where we will look at patient level data to ensure that the measure is actually measuring what we want it to measure. So through that testing process, we're looking at patient level data. But as it moves to the reporting set, then the requirement is to report aggregate data at that point.
DR. LUMPKIN: And do you see any of the standards that are currently being considered in the spectrum of standards that would hamper your process?
MR. TIERNEY: To the contrary, I think it's going to enhance that process. To the extent that we can standardize data elements across systems, it will ease I think the burden of, especially in the area of data transfer, it will ease the burden of health plans to calculate this data, collect it and calculate it.
DR. LUMPKIN: Anyone else? Randy, do you feel that standards would cause problems for the states?
MR. DESONIA: Not necessarily, in fact looking at cross border issues, going back to state health expenditure accounts, you know as well as I do that there's many major medical centers and hospitals right on a border. If you're collecting this information on your own state, you don't know how much represents people crossing the border. Only if you're going to get some type of standardization that permits that type of exchange would that be possible to work that way.
MR. MEROLD: Again, I think the standards will cut through a lot of the complications and facilitate more collection.
DR. LUMPKIN: The next series of questions I would like to direct at you have to do with the issue of coding and coding sets. One of the issues that we discussed at our last meeting was the extent that coding sets, for instance CPT-4 or ICD-9, that some providers use a restricted coding set where you can use CPT-4 but you can't use all of it type arrangement. Do you feel that that is a problem for the kind of business that you do? Do you think that dilutes the clinical information or you think that really doesn't present a roadblock to the kind of information you're trying to get from the patient records. We will start with Mr. Merold.
MR. MEROLD: The more latitude and variability that exists, the more it comes out significant dilution at the other end. We have significant challenges just in ICD-9 and many of the major disease states trying to differentiate what could be several types of clinical information, and specifically with some of the billing incentives for coding certain codes and not others. You have further noise factor to the point where we actually have to go back in some cases and sort of factor in what I will call an adjustment for what the ICD-9s are saying versus what it looks like from the rest of the data the ICD-9 should be saying.
So this is probably one of the most critical areas for us. It may get obsolete as electronic medical records become more prevalent, because that will in many ways obviate some of this issue. But for the next several years, the more latitude that exists, the more the value of what can be collected will be diminished.
DR. LUMPKIN: Let me perhaps clarify the issue of latitude. Latitude to the payer or latitude to the provider?
MR. MEROLD: From the provider side. Latitude of the provider in terms of classifying which disease state, which procedure is being employed and for what purpose.
DR. LUMPKIN: So you would be in favor of a narrow code set rather than --
MR. MEROLD: Narrower, yes.
DR. LUMPKIN: So some subset of CPT-4 or ICD-9 would be preferable to you?
MR. MEROLD: Yes.
DR. LUMPKIN: Okay. Any comment, Mr. Tierney?
MR. TIERNEY: I'm trying to understand that comment because I think it dilutes a little bit of what we're trying to do in trying to measure performance. What we're finding now in claims that are submitted to health plans, the absence of the fifth digit on an ICD-9 code dilutes in some cases what we're trying to measure. So I think it adds more noise by compressing that data set.
I think another issue though is that not so much the data sets that are out there, but education or clear direction of how to use that data set is required. Because of compensation arrangements or other factors, there could be -- we're starting to see where procedure codes and ICD-9 codes that are submitted don't actually reflect exactly the procedure that was given. So again, sort of --
MR. MEROLD: Let me jump in because your point is well taken. Our experience would say it's back to the prescriber physician education component. Smaller sets improve the quality of what you are collecting. Yes, we would love to see the fifth digit absolutely. The experience to date is that at this state of the art, getting good four digits beats five digits with a lot of noise. When we can get to five digits with quality, absolutely, it's the right way to go. I'm taking a practical walk before you run approach.
MR. TIERNEY: I think we're ready to run.
[Laughter.]
MR. BUCK: I think we've got our shoes on anyway. We're out on the track. I don't know if we're running yet, but we sure would like to try. I agree with the walk before you run approach. I think there's an enormous practical problem. It's even worse maybe, or more complex than we've said.
Just a comment, then I want to make one other comment. I don't believe today that if we were starting off today, not in 1950, but today, with the automation infrastructure that exists however flawed and varied it is, that we would really see DRGs come about as the prime focus. I think we're kind of stuck with this system that we've got now, but it focuses on this tension that you have so accurately put your finger on between aggregation and facilitation through that for certain transactions and then the necessity not to lose the detail that lets us harvest what we need out of this material to address other issues in as efficient a way as we can.
The accuracy issue is a real problem. From my awareness of this, good institutions, that is those institutions that are hiring and using skilled, trained data personnel for record management are likely to have about a 10 percent plus or minus error rate in coding. That's considered, at least I've been told, that that's considered acceptable in the industry today. It may be in terms of plus and minus reimbursement that it all balances out and who cares, but that's not adequate really for what we think we can and should achieve from a mature data system to support a lot of applications, quality oversight being one. So I would make that comment.
The other comment is I agree with the reservations that have been expressed about losing the fifth digit or let's say walking away from trying to get the more detailed statement. I will leave two issues that concern me greatly. One is -- and I think there's a lot of explanation -- but I am uncomfortable that we as yet have achieved the refinement processes that I think are really necessary either in the ICD-9 arena or in the CPT arena. I would perhaps leave that as a challenge for all of us that I feel there have been many controversies about frustration let's say with the timely refinements and updating of ICD-9 as well as CPT. So we haven't resolved that.
The other comment is we were talking about 800 pound gorillas. I have a worse case scenario nightmare. That is that with understandable frustration, simply because it's easier, financial people kind of go off into their own sandbox with their financial figures which really are objective somewhat, I guess mostly, and certainly easier to deal with than the clinical piece, and really never get involved in the integration process. I really feel that would be a tragedy. I don't think it's a likely happening today, but I don't think it's completely out as a prospect either. It would concern me greatly and I think that would be a tremendous setback for all of us.
DR. LUMPKIN: Let me perhaps clarify my question because you answered part of it. Part of it has to do with granularity, the amount of detail that's captured, whether you go to five or four digits. The other issue is that some providers use as subset sort of hemi-opsia(?), they get part of the field and they restrict providers to certain classes of a code. Do you feel that is a barrier to what you do or is that in your point of a restricted code set an advantage?
PARTICIPANT: It's the payers isn't it John?
DR. LUMPKIN: I'm sorry, payers. I'm sorry, not providers, payers, may restrict and say that you can only use this section of the code but not that section of the code, which is different than the granularity that we discuss.
MR. MEROLD: That restriction would be a problem, because you start forcing things into inappropriate classifications.
MR. BUCK: It's a pseudo-DRG kind of approach. I think my bias on it is that that is not constructive, would not be constructive, and I think we should try to figure out a way to walk through that and get to a better functioning level.
DR. COHN: I actually want to just as a slightly more global question because -- and Dr. Lumpkin, I appreciate the drilling in on these issues. I think as you've heard, as we've heard from you first of all, that administrative transaction and those data sets are probably not going to be sufficient to handle all of your data needs. I think we've heard that, we recognize that in a sense that's a second act of the committee to have to look at standards around electronic health records and more clinically related data sets.
I guess I would ask for sort of a more general view from the panelists, as we move towards the transaction data sets that we've been talking about, part of the committee's charge however even in this first act is to make sure that things are as extensible as possible and going to be usable into the future. Would you give the committee any advice as we begin to ponder that issue, as we recognize that administrative data sets don't solve all the problems, but recognize that we do want to make them maximally useful how you would approach that or what advice you would give us?
DR. BUCK: Just to lead off here, I think the support and leadership that you can provide in consensus forums is extremely valuable. I would not only commend the committee but hope that that will be continued. The second thing is that I think that all of us, and particularly you folks, and I know you do, but I think it's important to say, support every effort that can be made to support the larger National Committee on Vital and Health Statistics. The responsibilities here for, again I will use the term standard data set, is absolutely one of the most critical things, one of the biggest foundation blocks if you will, upon which this whole thing rests.
I think the charter responsibility of having a forum such as the National Committee to refine, expand if necessary, but refine the core data set project is absolutely critical to everybody's interests in this room. So those two things that I would emphasize for the committee.
MR. TIERNEY: I would echo that.
MR. MEROLD: I would echo that as well, but I will take advantage of the opening you've just given us. This is a moving target, as you well know, and I'm familiar with what Kaiser is in the middle of doing. What exists today will not exist in three years in terms of both the capabilities as well as the established infrastructure, as well as the basic ability of doctor friendly systems to interface with the health care system.
So I think it's important that we not try to shoot for 1996 or 1997 per se and that there be some appreciation for the change that the market is going through and that the standards not look retrospectively but also try to anticipate some of the capabilities that are going to emerge so that we are accelerating the deployment as well as the optimal use of those systems.
From my experience with a number of health networks, a large part of the billing administrative infrastructure is going to be regarded as legacy and I'm sure the folks in the next panel will talk more about that and probably don't view it as legacy as I do. But where the efforts are really going to be is in data warehousing, decision support systems, clinical records. So the billing system to some extent will be what it is, but the ability to surround the billing system with a number of additional information elements will make it a much -- one, will help the billing system, but also provide a whole other byproduct.
DR. LUMPKIN: Let me just ask a follow-up question because what would help us to understand is if we do the administrative component of that, which we're charged in the first portion, how far does that get us down the path in your needs for data standardization? Would you say that of the data elements that you use in your various activities, will that get us 50 percent, a rough ballpark, 80 percent, 90 percent, how much of the itch are we scratching?
DR. BUCK: I would probably go with a third. I think it's an essential and necessary start, and I would say totally important in a start.
Mr. Chairman, may I make one comment to what has been said I hope. I want to pick up on this looking forward, because that's perhaps a good way to add to our discussion. It's extremely important in my view to address the concerns that you've expressed, Dr. Cohn, and that is two technologies just for example. One, the data warehousing piece, new software. Another, the so-called variable electronic filtering software. These technologies will not solve, but go a long way to solving the issues of data based linkage and the construction, literally the construction of meaningful measures from I want to say many existing databases.
So we're on, in my opinion anyway, we're on the threshold of a major technologic breakthrough here. It would be sad not to anticipate that and make all the considerations retrospective. To me that view, and I believe that very strongly, that view is I would offer as not only support for this committee's efforts today, but for justification of continued work on confidentiality legislation.
DR. LUMPKIN: Mr. Tierney, how far do you think this will get us ballpark?
MR. TIERNEY: It's probably less than 50 percent, but again, I think it's the start. It's probably, from our perspective, the low hanging fruit. I think it's where we need to begin. As we learn more, I think we can add to this work.
MR. DESONIA: I would say the same thing. It's an essential start, but the concern is, with many of these types of efforts, because policy makers think of this as very technical, detailed, scientific work, it's solvable, easily defined and such. So there might be expectations on the outside that you're going to be 100 percent there after you're done with this effort.
So I think you also have to be considering about how you get this information to some higher level policy makers too and working on data and statistical issues generally. Once you start getting into the nitty gritty work, there's always a divergence of policy makers delegating this to individuals that understand the computer systems, the data elements but then they lose a vital connection to the people who do do the budget recommendations and propose legislation.
So that you want to try to make sure you interact with them, because I'm actually going to the gentleman's question about some of these global things. You've got a very tough task, because it can be too easy to sort of focus on the detailed issues and then be kind of surprised two years down the road when there doesn't seem to be much support or interest in what you proposed because they don't understand it and because they weren't part of the process.
MR. MEROLD: I think today a third to a half is probably a good number. If you look down the road, it's probably much less than that as you look at what can be done.
DR. IEZZONI: Can I just ask Dr. Lumpkin a question? I'm a little bit confused, John, because this goes back to the question that I asked at the beginning. To what extent are we talking about filling in encounter data versus the attachments that you told me the clinical data could be lumped into, because it seems to me that the response that you just elicited had to do with the kind of standard billing data, but not this wonderful opportunity for attachments that you kind of held out in clarifying my initial question? So I'm still a little bit confused about where we are.
DR. LUMPKIN: I think what we've heard, at least my interpretation would be is that if we were talking about the administrative thing getting us 95 percent of the way and five percent was missing --
DR. IEZZONI: So the billing part.
DR. LUMPKIN: The billing part, right. Then the issue of attachments becomes a five percent issue. But what I think we just heard is that the issue of attachments, if there is missing stuff, is really much larger than the issue that the billing portion is, then I think we have to view the attachments component to the extent that it's part of our charge, but how much of a doable part of our charge is it. I think that's where what we're trying to assess the magnitude of.
DR. IEZZONI: Yes, I think we need to be clear.
MS. COLTIN: To build on that, I'm struck as I'm listening to this that there are some common threads that I'm hearing. One of them is not only that for the purposes of performance measurement, the standard billing transactions go less than halfway to where you would like them to go to be able to accomplish your purposes. The other was the advice to look to the future and where things are heading.
When we look to the future and where things are heading, we're seeing capitation as a form of payment replacing fee-for-service. In that environment, I have to question what the purpose of the health care claims or equivalent encounter transaction is and is the purpose of that transaction to pay a bill, which is the way it is currently being viewed and the way those who are party to developing the standards are viewing the various data elements that come up for consideration, or will in fact in the future the purpose of that transaction itself change dramatically to one of oversight, regulation, monitoring, performance assessment, appropriateness evaluation, et cetera?
In that environment, I would bring you back to Lisa's first question which is what would you add to that transaction as opposed to viewing the attachment as the big bandaid that fills the gap. What's missing from that transaction data set for the future environment in which that transaction is likely to be used?
DR. LUMPKIN: Let me first make that a two part question. Part one you can answer --
PARTICIPANT: That wasn't complicated enough?
[Laughter.]
DR. LUMPKIN: Part one, please feel free to answer now, and part two is to take some time when you leave today and to submit some written comments in as much detail as possible to answer that question, because this is a process that's going on. Your time to have input doesn't end when you leave the table and a more detailed written response would also be appreciated.
DR. BUCK: Let me lead off. I think that what you're describing has already happened or is happening. I think the concept of having some kind of a transactional standard form is fairly anachronistic already. What is emerging I think is a good thing and a necessary thing and that is, but looking to the future, having this information in one place is really the lock on the resource commitment compared to or related to the clinical data. And let's say the more sophisticated application of the UB92 right now by many organizations that I'm familiar with is to establish for their own internal management purposes that link between clinical activity, whatever it is, clinical burden, whatever it might be however imperfect we describe, and some gross and still as yet very imperfect assessment of resource commitment as it relates to those things.
You asked what's lacking. Well, for openers, an example, the universal patient ID. This is one of my pet windmills. The point is can we do continuity of care? No. Can we really build meaningful episodes of care? No. Can we really follow patients from plan to plan? No. I kind of rest my case.
If you want other examples, and I will give you one more and then I promise I won't say any more on this, but another example is much more profound in a way even. The implication for instance that by billing we're actually assessing cost totally falls. I know that that disconnect is well known to the National Committee, but it's not well known to the public. It's not well know to the politicians, and it's not well known to many HMO managers even, let's say some.
But the point is that this is a serious, and I would even be so bold to say dangerous, situation to have a large volume of people participating -- and I mean significantly participating in health care management who themselves are confused about what we really mean about costs and where that data really comes from and how accurate is it really anyway. So I would say, okay enough, thank you.
MR. DESONIA: One thing I would suggest you be looking at is the chronically ill population. We're now going to see much more massive enrollment of these special needs populations in the next five, six years in which they will be going to multiple providers, they will be using at times substituting welfare or social service type services in place of the regular medical model type services. We just don't have an information system that can really sort of track that small population, but in terms of cost in terms of attention from the medical community is very large. MR. MEROLD: Our experience is in a capitated environment, the administrative quality records to hell in a hand basket to put it bluntly. There's no incentive for anybody to keep up the records and it is very sporadic. In that context, it is only the clinical information where you can get an understanding of what lab tests, what procedures are done, what therapies are implied.
There's another dimension to it which is who is going to bear the ownership for the quality of care. I think it's important to say, it's been inferred before, but I will state it bluntly, that the bigger opportunity in cost reduction and simplification has to do with what care is provided not in terms of optimizing the cost structure of the billing system. In that context, using information which can only be in the capitated world a clinical information record to identify the procedures that produce best outcomes for the patient and those which may do something but in the longer run are either counterproductive or ineffective or less effective than other procedures is really at the heart of the broader issue of cost containment.
MR. TIERNEY: In looking toward the future, I'm wondering if the assumption is that we will have some sort of transaction, whether it's fee-for-service or an encounter form or the work that this group is beginning, the standardization of data elements allows for the access to those databases rather than the transfer of that data. I mean I think technology is advancing to the point where you don't need to have a central repository, you need access to repositories. So that encounter form I think or whatever this form we're going to call it, I think really becomes obsolete. The standardization of those data sets allows, and the standardization of those transactions allow for you to access the different data sets that you need.
Again, it goes to the common patient record, the common provider record, the electronic medical record. Once that is electronic, we have the infrastructure in place where we can access that information.
MR. SCANLON: Several of the panelists mentioned earlier that several states I think had already begun through legislative means, had begun to implement standards similar to this, transaction standards and others. Could you say a little bit more about that and what are the features of those programs that might be worthy of emulation or on the other extreme things that should be avoided.
MR. DESONIA: I can help you identify those states. I mean they've worked with some of this in much greater intricate details and they've had to work with providers, they've had to work with Medicaid agencies and purchasers as to what would be needed. Frankly, just how do you get the medical community up and running into that type of system. That requires substantial investment on their part too. But I do know of New York and I can direct you to the right people there and I'm sure there are some other states, Massachusetts too.
MR. SCANLON: Has the starting point generally been the more or less ANSI type standards that exist now or have they more or less taken some other route?
MR. DESONIA: I can't say.
DR. LUMPKIN: Other questions? I would like to thank the panel. At this time, we will take a 15 minute break.
[Brief recess.]
DR. LUMPKIN: Before we get started with this panel, I would like to call everyone's attention right after it says adjourn on the back of today's agenda, it says visit the NCVHS Home Page and it gives a URL. That home page we have all of the written testimony that was submitted at the last hearing is already up there, as well as the transcript, the verbatim transcript. As soon as it's available from this meeting, any electronically submitted testimony will be available quickly and the transcript probably within a couple of weeks. I would encourage anyone who is interested in getting copies of that to just surf over to there.
The next panel is on electronic health care transaction transmissions and we will start with Ben Curtis.
MR. CURTIS: Thank you. Good morning, members of the Subcommittee, Dr. Lumpkin.
My name is Benjamin Curtis and I'm Vice President of Business Development for The Health Information Network Connection, or THINC as we're commonly referred to. I also serve as the current Chairperson for the Association for Electronic Health Care Transactions or AFEHCT.
I would like to thank you for the opportunity to address the subcommittee. On behalf of the organizations I represent, I would like to say that we're pleased to know that you recognize that there are some tensions that may exist between those who generate the information which goes into an electronic health care transaction and those who use the information.
I would like to tell you a little bit about my organization, or both organizations, THINC and AFEHCT. First, THINC is the new state of-the-art electronic health information network that will allow physicians, hospitals, diagnostic centers, laboratories, payers and other health care entities to access their patients' clinical and insurance-related information through their desktop computers. THINC facilitates the electronic exchange of business and patient-care data through a private electronic intranet system. Our company, along with the other members of AFEHCT, support the health care industry in its efforts to streamline the exchange of information in order to reduce cost and improve the efficiency of management of patient care.
Most recently, during the President's State of the Union, you may have heard him mention that each person or child should have access to various information that may reside either over the Internet or within the hospital setting. Well, THINC and the members of AFEHCT are those entities that actually will be making that happen.
This morning I am joined by members of AFEHCT who represent organizations that fulfill various functions in the process of generating and transporting electronic health care transactions. AFEHCT is a trade association of vendors and suppliers to the health care EDI industry. Our membership includes health care information clearinghouses, software vendors, payer organizations, value-added networks or VANs, banking and credit card companies.
The organizations I represent have several expectations for the results of the administration simplification standards requirements in the Health Insurance Portability and Accountability Act of 1996. However, I will state three of the most commonly known expectations, passage of the Act which provides an incentive to the health care industry to take advantage of the multiple benefits of utilizing standard transactions and transaction sets to communicate data electronically. This is also an opportunity for the development and use of a uniform implementation process of the standards intended for transmitting and receiving electronic data. Third, this increased availability and even more significant will be the increased use of electronic health care transactions.
One of the things that AFEHCT was definitely known for during the early development of the Act was the fact that we do recognize their are standards. The industry has moved forward in creating these standards, but there hasn't been a wide use of those standards mainly because of the implementation guides that until recently did not exist.
The outcome of the standards requirements of the Act mostly affect THINC and other members of AFEHCT in a positive manner. It is the part of our association's mission to promote the use of electronic health care transactions. While alternative methods to electronically exchange health care data may exist, electronic data interchange or EDI is believed to be the most beneficial method. Other industries such as the banking and pharmaceutical industries have taken advantage of this process.
We believe the increased availability of transaction standards and accompanying implementation guides will assist small business survive in an extremely competitive market. The existing market fragmentation is likely to decrease, which will allow the end users of the data to become more secure in their decision of selecting a vendor. Too often, the end user is forced to select a vendor that provides limited functionality. As a result, he or she must engage the services of yet another vendor to augment the desired functionality. The possible negative outcome will be the continued absorption of the small health care EDI company or the small software vendor. Some market analysts may argue that the Act will increase the rate of industry consolidation.
AFEHCT was one of the many organizations that sought the passage of federal legislation that would define the parameters and create incentives for the expanded use of these health care transactions, particularly the use of standards to accomplish this task. It was through AFEHCT's diligence that implementation guides became a point of consideration within the Act. Additionally, it was the members of AFEHCT that began to make the use of electronic health care transactions as a method to reduce the cost of administering health care an issue for Congress.
We applaud the process being undertaken by the Department of Health and Human Services to carry out the administrative simplification requirements of the law. However, we were originally concerned that the Department may exclusively consult with the four organizations explicitly listed in the Health Insurance Portability and Accountability Act of 1996. This is primarily due to the fact that none of these organizations actually represent the broad spectrum of concerns raised by members of AFEHCT.
I am pleased to know that the Department is reaching out to other interested stockholders with direct responsibility for implementing all of the provisions listed in the Act. The organizations I represent welcome the opportunity to consult with the Department and its various agencies and committees. In fact, AFEHCT has prepared an extremely detailed presentation designed to familiarize government entities with the various types of organizations and their relationships who play a significant role in the creation, utilization and transportation of electronic health care data. We would be delighted to discuss making this available to you.
The members of AFEHCT experience the customary problems of implementing change as other business entities experience. There is, however, the additional anguish of convincing our customers that the changes being implemented are for their benefit and the benefit of their customers. Unfortunately, the immediate administrative simplification provisions lend themselves to financial transactions. This is understandably necessary because clinical transactions are much more complex than financial transactions. The readily available information required to populate a clinical and financial transaction resides on separate systems within an institution or a physicians office. Often this data resides at a separate site.
From the Health Information Network Connection's perspective, this does not represent a problem. We have devised a solution that will provide access to this data, regardless of physical location in order to enable the increased efficiency of delivering health care. It supports the intense needs of working within a managed care environment. Most importantly, our solution based on proven strategies will ultimately result in the improvement of patient care.
In conclusion, the goal of administrative simplification can best be achieved while meeting the business needs of all stockholders by continuing to allow the stockholders the opportunity to be heard prior to formulating policies. It is a proven fact that including one in the process of developing the rules by which one is expected to play is far more productive than dictating behavior.
Thank you for the opportunity to present our perspectives on the critical issues associated with administrative simplification. The Association for Electronic Health Care Transactions and THINC look forward to a continued productive relationship with the National Committee on Vital and Health Statistics.
DR. LUMPKIN: Thank you.
MR. BLASZCYNSKI: Good morning. I'm Denny Blaszcynski and I am with IBM's Global Network and I'm also Vice Chairman for the Association for Electronic Health Care Transactions.
I would like to thank you in advance here for your invitation to our association to speak on the matters related to the health data standards as covered under the Act. I will be responding to the questions you provided in your invitation on behalf of and the viewpoint from our value-added network members.
Just to give you a very quick overview of the term VAN, the value-added network, you might look at it as the linkage or connection between trading partners doing electronic commerce in multiple industries, which includes the health care industry and the electronic highway type of connections that are provided bring to it value-added services such as network management of those connections and communications, security and authorization between authorized trading partners, and mailboxes for store and forward of EDI type transactions which include health care transactions, and some e-mail services, bulletin board, access to the Internet, et cetera.
So first, let me make a general statement in response to the initiatives forthcoming from this legislation. From a VAN member perspective, we wholeheartedly support the adoption of standards as provided under the administrative simplification provisions of the Act. We feel the enactment of these provisions will do more to foster and encourage the use of electronic health care data communications than any other means previously undertaken by the private sector. We believe that the mandatory use of these standards will bring efficiency and cost effective solutions to the electronic exchange of health care data.
The health care industry is finally moving toward a goal of electronic efficiency rather than the maintenance of manual complexity and the high costs associated with this method of handling and processing health care data. Over the last several years, this industry has realized the need to move to an electronic media. The problem was that there are so many disparate players with different agendas and reporting requirements that it has stifled the effective use of communication technology and brought a high degree of cost and complexity to the system.
The health care industry is just one of the many industries who utilize electronic data communications. Unfortunately, it has been lagging behind other industries in the effective use of electronic data handling for two reasons. One has been the lack of investment in the technological communications infrastructure needed beyond the campus or the enterprise, namely the hospital or the hospital enterprise, the actual doctor's office, the clinics, et cetera. The other is the influence and complexity that the multiple adjudicators of the health care data community has brought to the current system through the use of numerous proprietary transaction requirements and disparate communication systems, access and enabling.
Establishment and mandated use of standards will bring significant improvement through the establishment of consistent methods of handling, reporting and communicating health care data. This should provide the jump start this industry needs to catch up in the effective use of electronic commerce.
Although these actions will reduce costs and improve the efficient and effective use of health care data, many of the requirements for the submission of health care data will continue to require a substantial amount of technical and administrative support. There will continue to exist a requirement from the provider for expert services to install, implement and maintain their current and future applications. These applications will both input as well as extract clinical and health care encounter information, perform coding, edits, analysis reports and engage communication protocols to assimilate and transport the data. Therefore, the business opportunities will continue to be available to the participants within this industry. Our members will continue to play a key role in the management and handling of health are data.
We believe that the constituents in this industry are in a position to respond to these actions, make the investments in technology required and move to the next level of electronic commerce. This will include both utilization of specific health care encounter information as well as populating and providing access to repositories of general health care and maintenance information. The real challenge will be for this industry to get motivated and embrace the idea that they can only achieve efficiency and cost reductions by agreeing to a standard way of assimilating and communicating its health care data.
Therefore, we applaud the direction and actions being taken by the legislative initiative, however we do have some concerns. A downside could be realized should there be an overzealous desire to over protect the movement and handling of health care data under the guise of privacy and confidentiality. We must be cognizant of the differentiation between security and privacy and confidentiality. The use of technology in the transport and handling of health care data can provide the levels of security needed to provide a highly efficient means of authorized handling of data. To that end, the electronic highways provided by VANs and network service providers to accommodate this level of information management and access are in place and expanding every day.
The ability to route EDI transactions based on the message header provides the means to move these messages from authorized trading partner to authorized trading partner. This provides a simple method of extended delivery. Most VANs envelope or encapsulate the transaction and rely on the header information to deliver the message. They do not open the envelope to review or modify the data in most cases. If they do open that envelope, it's normally to do electronic formatting. It is not normally reviewed, it is handled electronically by applications.
The VAN does not know what type of data exists within the message thus maintaining a high degree of security in the handling of data. So the movement of electronic transactions in an EDI environment across VANs or the electronic highways encapsulated within envelopes the messages could be from any industry, could contain any kind of data. It is not looked into.
Unfortunately, it cannot ensure that an individual who intends to obtain and misuse the data will be absolutely unable to get to that data. This is especially true for data which begins or departs from the Internet environment. the Internet environment does not currently provide the level of network management, service, control and security that you would expect from a secure intranet environment. These intranet environments are the value-added organizations such as VANs provide to the EDI user community. In the past, we've known the intranet terminology is private data networks.
The reality of the situation is that health care encounter data is always available beginning from the time it is documented at the provider's location up until such time that it would be totally erased or eliminated by or within any organization or organizations that created, opened, stored or reviewed the data. A reasonable requirement for security in the movement and handling of health care data should be expected and we support these requirements. As vendors who provide services to the payer and provider community, we are consistently addressing security measures and we will continue to enhance these activities as new and better technology come into play.
However, the fact that someone elects to illegally obtain, view and/or use the data, break any security or authorization coding or overtly access a telecommunications line demonstrates a willful attempt to appropriate and subsequently misuse that data. It is this breach of privacy and confidentiality that must be addressed and penalized. Actions must be aimed at adopting strong penalties and disincentives to address any specific actions undertaken for the unauthorized access and use of private and confidential data. Therefore, we look to the laws of the land to control and respond to any illegal, unauthorized access, accumulation or use of data deemed proprietary and confidential. So it is our hope that a clear distinction is made by the Secretary, and by the panel who makes the recommendations, that would be provided to address the matter of security versus privacy and confidentiality.
If we over react and put too many constraints on the ability to move health care data, we will severely impact the system that's currently in place today for moving data through electronic means and believe the security measures that are in place and will continue to be improved will certainly act in a good measure to maintain security of that data. When it comes to the privacy and confidentiality, it's really the use of that data and the misuse of that data that needs to be addressed. So that was an area of concern and we would like to have a clear understanding of that.
AFEHCT has been conducting, in concert with HCFA, several vendor meetings to discuss subsequent development and move to a new Medicare transaction system. So one of our areas of concern is the general process in which the Secretary will proceed in defining and recommending solutions to respond to the administrative simplification provisions of the act. We highly recommend that the Secretary sponsor a series of workshops designed to engage the numerous vendors associated with the generation, transport and processing of health care data.
We believe that forums such as the testimony we are able to provide today are of great health to the subcommittee and its charter. However, a clear understanding of the real world activities in the marketplace cannot be addressed in short testimonials and white papers.
The meetings that we have had with HCFA have been very enlightening to both HCFA and the vendors in defining the reality of the movement and handling of health care data. As we are all aware, the most proficient means of obtaining and moving health care data would be for a point to point connection and communication of that data between provider and adjudicator. But as discussed earlier, this is not the reality of the marketplace.
Providers of health care desire to practice medicine and not engage in bookkeeping, financial tracking and networking communications. They engage third party service vendors to handle many of the computing and network communication tasks that are necessary to stay in business. Therefore, along with the providers, these service vendors play a critical role in the accumulation, processing and transport of health care data. They will continue to play the middle man role in our health care system. It is through their competitiveness and technological enhancements and investments that we continue to improve on the ability to move to a truly electronic commerce model in health care.
Thus, our recommendation is for the Secretary to engage and invite a cross section of these vendor service organizations to participate in workshops which would provide an open forum that could focus on addressing the issues and assist in defining the electronic commerce solutions that the Secretary must recommend to Congress in the time frames required in the legislation. Our industry association stands ready to assist and participate in these activities.
I would like to thank the committee for their invitation and attentiveness to our testimonies today. We look forward to a continuation of this type of dialogue and will do all we can to assist the process associated with meeting the provisions of the legislation addressing administrative simplification for health care data. Thank you.
DR. LUMPKIN: Thank you.
MR. ZUBELDIA: Good morning. My name is Kepa Zubeldia. I want to thank the subcommittee for extending the invitation to AFEHCT and to me and to Envoy NEIC in representing the members of AFEHCT to explain what the clearinghouses are and what we do and what we expect and to try to answer the questions that you posed in your invitation.
In preparing today's presentation, I want to emphasize that it's not Envoy NEIC that I'm representing. I had meetings with multiple clearinghouses, large and small, and I'm bringing a general clearinghouse concern to this meeting.
Since the clearinghouse role is not very well understood and we're sometimes confused with VANs and billing services, I'm going to take the first few minutes to explain what is a clearinghouse. The administrative participants in health care are principally physicians offices, hospitals, pharmacies, dental offices, other providers on one side, on the other side payers, HMOs, Medicare, Medicaid, other government payers and there are durable medical equipment suppliers, ambulance, and a number of other entities. For simplification purposes, I am going to show only those six that you have in your letter. If you want to follow along with me, my presentation is on page one.
This is a very reduced set of players that are used for explanation of the connectivity of requirements. Can you go to the next slide?
Among that set of six players, there is 15 possible relationships that can be established. The physicians talk to each other, they talk to the hospitals, to the pharmacies, payers, HMOs, HCFA. The hospitals do the same thing. And not counting the relationships within each other, physician to physician, not counting the relationships to the patients, there's 15 different relationships with six players.
The complexity of this kind of network relationship increases exponentially. As you enable more partners to take part of the diagram of the connectivity, you will see an explosion of the connectivity. We have in table one some explanation of the calculation of the different connections. The numbers are subject to debate. I found that there are some errors in here, there are about 55,000 pharmacies and 5,000 hospitals, but they don't significantly impact the number of relationships.
You will see in the table that I'm calculating the physicians, each one of them will talk to about 20 other physicians and will talk to about 15 pharmacies in their town, five hospitals, 400 payers out of the 1,700 possible payers, to five HMOs out of the 400 HMOs. So this is trying to calculate how many real relationships, rather than theoretical relationships there are.
If we follow the table, we will see that there is over 57 million relationships that will have to be established on a point to point environment between the physician or the hospital, the pharmacy, the payer, between the different parties. Less than 200,000 parties will establish over 57 million different trading partner relationships.
Now, I'm not talking about data standards here. I'm talking about business relationships. Each business relationship will be represented by multiple data standards. You have to implement claims and payments and eligibility and referrals and other transactions, so you then multiple the 57 million relationships by about three or four different standards and you get the magnitude of our administrative complication that we have today.
Now clearinghouses bring the level of administrative simplification to the picture. If we use a clearinghouse to establish the relationships, the physician, the hospital, pharmacy, the payer, the HMO and HCFA would have one connection to the clearinghouse. We can reduce the 57 million relationships to under 200,000 relationships. And this will bring real administrative simplification.
This is what is happening today. Clearinghouses are moving towards administrative simplification. We have been doing this for about 15 years. We've been laying the infrastructure that will support administrative simplification in this way.
Now, the reality of the world is not as simple as that diagram. There is more than one clearinghouse. In reality, you will see a real connectivity of multiple clearinghouses, multiple VANs, the connections, the combination of billing service provider clearinghouse and VAN connectivity that even this diagram is a simplification of.
The reason why this works is because the clearinghouse is a trading partner. It's not merely a conduit of information or a data processor that provides translation services or a value-added network. A clearinghouse is a true trading partner with the physician, with the hospital, with the HMO, with the payer. If it was just a conduit of information, the clearinghouse would not simplify the picture. But being a trading partner, the clearinghouse can simplify the administration of health care administrative information. This point of the clearinghouse being a trading partner has been missed many times and this is one of the reasons why we're so happy to be able to present to this to the subcommittee.
Technology is a secondary issue. Clearinghouses today possess the technology required to implement the standards. In fact, the clearinghouses are moving the standards. But without the standards, clearinghouses as long as they continue being trading partners could still bring simplification.
Now, the typical scenario of a clearinghouse as trading partners will show multiple clearinghouses as multiple trading partners. There is a chain of relationships. Typically, the provider will contract with a clearinghouse that the provider chooses as their preferred trading partner. The payer will contract with a different clearinghouse as their preferred trading partner. Thus clearinghouses may or may not have a direct connection between them. They could be one and the same, they could be connected distantly through another national clearinghouse or a chain of national clearinghouses.
A typical scenario would be a three layer scenario. The provider chooses a clearinghouse, the payer chooses a clearinghouse, a national clearinghouse connects the other two.
In this scenario, we have five trading partners, the provider, the provider's clearinghouse, the national clearinghouse, the payer's clearinghouse and the payer itself. Now, it seems like a chain of five trading partners without administrative complication, but in fact it adds a tremendous amount of simplification because it reduces the network expansion explosion of trading partners.
Now, there is one exception and we're handling this exception the best we can. Because of administrative regulations, HCFA and Medicare, Medicaid have never contemplated the clearinghouse as trading partners. So clearinghouses are having to deal as mere conduits in that environment and allow the connectivity of the provider as the trading partner with Medicare, Medicaid as the other trading partner and the clearinghouse being invisible. The complexity that this adds is surmountable. Considering HCFA as the large 600 pound gorilla that they are --
PARTICIPANT: I got reduced.
[Laughter.]
I used to be an 800 pound gorilla.
DR. ZUBELDIA: Most people can deal with HCFA very effectively. Anyway, because it's only three trading partners that each provider or hospital has to deal with, they only represent about 310,000 of the 57 million relationships. So if we go to 200,000 relationships with the entire industry and an additional 300,000 for HCFA, that's still a manageable level of complexity. Now, we hope that HCFA will recognize clearinghouses as true trading partners and will come to the fold as the rest of the industry.
There are some issues that affect clearinghouses. The first one is privacy and confidentiality. One of the concerns of clearinghouses is that as a trading partner, we have to maintain information submitted by our trading partners for retransmission. Typically, we will maintain it for 90 days, and retransmit any failed transmissions. We have to maintain the privacy of this information. Health care information has a lifespan of over 50 years. Financial information has a lifespan of maybe two to five years. Credit card information at most two years. All the encryption methods that are being used for banking and credit card and Internet information could not be adequate for health care information if not used properly, because they have to protect the data for at least 50 years.
Clearinghouses also understand the data that we handle is not our data. It may be the provider's data, it may be the payer's data, it may be somebody else's data, but it is certainly not ours. We cannot sell it, we cannot use it improperly other than for the use it was allowed to.
In order to proactively protect clearinghouses in this environment, the clearinghouses have submitted voluntarily to accreditation, to EHCNAC, the Electronic Health Care Network Accreditation Commission. EHCNAC takes a look at how clearinghouses maintain privacy and confidentiality, how they maintain security, quality, responsibility, et cetera. Clearinghouses on the security side act frequently as the gateway and the fire wall between the provider and the payer and the rest of the industry. Minimum functionality of clearinghouses is to send claims and send the corresponding messages back to the provider, but there are many, many other functions that a clearinghouse will provide.
Clearinghouses are responsible for the data that we transmit. This is in sync with being a trading partner. When we receive the data, we acknowledge it, and we are responsible for it. A payer typically will lose part of the data that they have received. A provider typically will lose part of the data that they receive. They look at the clearinghouse for backing up the data and retransmitting to them as they need. We constantly retransmit to the payers and to the providers claims, reports and other transactions that they lose at their end. In that sense, we act as a repository of their data for back-up purposes. I want to emphasize that I said their data.
Managing the complexity is one of the strong sides of a clearinghouse. For instance, it's a routine work for a clearinghouse to accept multiple transactions from multiple providers, break them apart and recombine them into one single transaction for the payer that we're sending to. That way the payer will have reduced complexity and the provider will have reduced complexity. These outgoing queues that we maintain for distribution would overwhelm any of the other trading partners that we work with.
Another issue that affects clearinghouses is regulation. Each state has had the tendency to regulate clearinghouses in their own way, most of them without understanding the role we play. We're looking at the states using EHCNAC as the means to establish the uniform regulation of clearinghouses.
As solutions to these issues, we have organized in effect for a clearinghouse network commission or network group. We adopt EDI standards to reduce the complexity of our own trading partner relationships, and we are the strongest pushers of EDI standards. In fact, if you look at X12 EDI, you will see many more clearinghouses than providers in X12 EDI. Clearinghouses are definitely behind the EDI movement, behind the standards movement. However, the application of standard sets, transaction sets would not reduce the complexity per se, could even increase the complexity that we have today if it's not used properly, and without data standards will not really achieve much.
We also look at accreditation with EHCNAC as a way to solve our different problems and different views of clearinghouses. EHCNAC doesn't look at how you achieve the results, EHCNAC looks at the results that you have achieved, it looks at outcomes not how you do it. This lets the clearinghouses maintain their own independent way of doing things.
We also want to participate in the process. We want to help the committee, help HCFA, help other people achieve the goal of administrative simplification. We have experience in it, we've been doing it for 15 years.
What we expect of the Health Insurance Portability and Accountability Act of 1996, we see this as an investment in the future. We see it as an expensive investment, but it will pay off. It will increase the number of players and it will increase the variety of transactions, it will increase the number of transactions, it will reduce the cost of health care administration and it will simplify the current complexity.
We expect wide adoption of EDI standards. Standard transaction sets, standard implementation guides, standard data requirements, we heard about it this morning, a standard data dictionary and data definitions, standard identifiers, standard trading partner agreements, standard clearinghouse accreditation, we're looking at these things to simplify our life. We're looking at administrative simplification out of the Act.
Concerns that we have about this situation, our role has been mostly misunderstood. We've been thought of as being a value-added network or as being a conduit between two endpoints, when in reality we are one of the pivotal center points. There are inadequate contractual relationships. Our relationships with HCFA, our billing services were not contemplated in a lot of the contractual relationships around. And although EHCNAC has done a lot of work in that respect, and it's all sponsored by AFEHCT members, we need to improve the situation.
We have a concern about digital signatures and encryption. We're concerned that the technology applied indiscriminately will impede the work and in fact will put the clearinghouses totally out of the loop. If the data is encrypted from the physician to the payer, the clearinghouses will not be able to operate, even see the data, which means we will go back to administrative complication with 57 million relationships. If the data is signed between the provider and the payer because the clearinghouse has to reorganize the data to achieve the efficiencies, we will again create a great complexity. If the provider has to maintain, and the payer has to maintain key rings to validate the public keys of all those participants, we again go to a great complexity.
We're also concerned about the fact that EDI standards are not mandatory. Even with the Act, they're not mandatory. Let me read with my own emphasis one of the sections, Section 11-75 A1. It says, "If a person decides to conduct a transaction referred to in Section 11-73 A1 with a health plan as a standard transaction, the health plan may not refuse, blah, blah, blah." If you desire to conduct it as a standard transaction, you have to use the standards named in the Act. But if you decide to conduct a transaction as a non-standard transaction, you can just flat out ignore the Act.
We fear that by adopting standards, the standards will become an adopted child and the other children, although standard teenagers that we have, are not going to be kicked out and they're going to be running around for very many years.
Data requirement standards, even if we have standards for transaction sets, we need to have standards for the data. Date requirement, we're looking at something like a standard requirement that will satisfy all of the needs. Is it correct to request from a provider the name of the employer of the spouse of the patient. It may give a certain amount of help in processing the claim and it may result in a better coordination of benefits, but at what cost and to whom. Who is paying the cost of gathering that information that is required by the payer? Certainly not the payer.
We're also concerned about multiple state regulatory requirements. We've seen a proliferation of this with the CHINS(?). Now that the CHINS are dying, we hope it will clear up the situation.
Suggestions for the committee. We want to have increased clearinghouse involvement, we've been doing this for 15 years. We have something that we can bring to administrative simplification. We would like to see standard EDI trading partner agreements that specifically represent the role of clearinghouses. We would like to see clear and unambiguous policies that cannot be misunderstood. We want to see incentives to early adopters of the standards. There are some disincentives already, but we want to see incentives.
We would like to see standards for data content requirements, standards for compliance verification. This is a pet peeve of mine because payers send us all the time transactions that do not comply with the standards and as a clearinghouse there's nothing we can do about it. We cannot reject it back to the payer. They're the holy cow and if they send something not compliant, sorry, tough luck.
We also would like to see a requirement for accreditation of clearinghouses through the EHCNAC process. These are the suggestions that we bring as clearinghouses to the subcommittee. We thank you for the opportunity of presenting testimony today.
DR. LUMPKIN: Thank you.
MR. SCOTT: Following Kepa reminds me of an old vaudeville saying, but I won't go into that one.
Nonetheless, I'm Jeanne Scott and I'm the immediate past Chair of AFEHCT and I'm here both on AFEHCT and as Director of Government Legal Affairs for CIS Technologies, which is a Division of the National Data Corporation. I'm here kind of uniquely for me today in that I'm representing maybe more of the pharmacy side of the issue, and some of the issues that come up for the pharmacy programs. Normally I'm wearing a different hat.
But just a little brief history in that area, because I think what Kepa has said and what we've heard today, you have to recognize we just started this whole administrative simplification process the legislation I think, at least I did, six years ago. I think there probably were a few people who were pushing some legislation before that. One of the first things we discovered when we went up on the Hill and even began talking to HCFA is they thought they were inventing the wheel. This industry was already there. We were already doing so much of this, not as efficiency and effectively as we want, and standards have always been our goal because it makes it more efficient and effective. But we were doing it and this industry was out there, and we have been doing it.
In the pharmacy area, I think it is an amazing experience because today probably close to 98, 99 percent of pharmacy transactions are going electronically and are going smoothly. Our one fear I suppose, and I will jump to the end line here, is that in setting up standards we could somehow upset that apple cart, that we would overturn what is already a very effective and efficient system on the pharmacy side, by somehow requiring the whole pharmacy system to adopt to a new standard. So we want to look at that.
The National Data Corporation, which I work for, processes over 2.3 billion electronic transactions annually, over 850 million health care transactions. They do some banking and other financial transactions. They are doing this in a smooth, there's seamless process to the end users of the service. At their peak last year, the highest they ever achieved was 313 transactions in a second through their data centers.
On the health care side, we are the largest pharmacy transactor and the largest hospital, UB92 transactor, and the second largest on the physician side and the 1500.
In terms of the HIPAA, Health Insurance Act, Kassebaum-Kennedy, K2, whatever we want to know it as, we see this as our end product. We have been supporting the legislation as I said for six years, since I got started in this process. We couldn't be happier, we celebrated. I was toasting for a week afterward the passage of the bill because of what we see and our expectations, solving so many of the problems that we have had in building the network and making it work.
But we also have some fears, and some of the fears, like I say, are the concerns about the legacy system, looking to the costs of making some of the changes. This is represented at this table, the American private sector that is building the information highway, the network. I think we have all too often focused on just the providers and just the payers and we haven't looked at those who build the network.
Just looking at, for example, making the changes to go to the year 2000 this past week, I think it was something like $3 to $5 billion was the estimate for the federal government alone to make the change, and that was being criticized as being way too low an estimate. If we suddenly had to make substantial changes in the systems, just the lines and credits. We're doing 800 million pharmacy transactions a year at NDC. If we raise that by a cost of one-half cent, that's $4 million in addition costs. If we raised it by a penny, and this is our estimate, somewhere between a half penny and a penny, transaction costs would go up if we had to switch and change systems, we're talking about $8 million, somewhere between $4 to $8 million in terms of the processing. Just that one aspect in terms of communication costs, not the other editing costs and other changes that would have to take place.
Pharmacy is the only market segment in health care representing here. We have the hospital and physician markets as well where we have full claims adjudication and clinical screening at the point of care. It's taking place today. It's not something that has to be invented. Each transaction typically takes less than 30 seconds, more like about 20 seconds really from call up to response to take care of that time and the point decisions are made.
For this reason, in the area of pharmacy EDI, we ask that the subcommittee recognize and endorse the standard NCPDP, telecommunications standard that's already in place. This is an ANSI accredited standard. It's not the X12 N standard, but it is an ANSI accredited standard already in place in the pharmacy market sector. We want this committee to preserve the pharmacy sector's investment and its focus on changes that are clearly tested and already cost justified, and to focus on developing plans that ensure standardization within market segments leading to interoperability. Our ability in the pharmacy area to relate our data to the hospital, to the physician side is clearly an area that we need to assure that that capability is not in any way compromised, because we need to look at the data, we need to be able to talk to one another, as we focus on the interoperability aspects of it.
The potential problems, as I said, in the area of changing this growth that has already taken place and in any way compromising what has already occurred is I think the major concern that we face and why I stand a little bit distinguished from the others in this panel today.
We caution -- looking at the HIPAA standardization mandate, the committee in making its recommendations to the Secretary and to the nation must be careful not to needlessly undo or burden what is currently working, and you need to understand what is currently working most effectively and cost efficiently, particularly I think, looking at the hospital in-patient sector as well as the pharmacy sector, which are already very highly automated in the financial transaction areas.
I think we do need to be looking at how we can better serve the physician and hospital out-patient areas where there's still substantial room for growth.
Administrative simplification can best be achieved by recognizing and focusing attention on those areas where standardization has been most difficult to accomplish, accepting what's already done, but looking at the difficult areas. In those areas where standards are already widely accepted and implemented, continue to endorse and promote their utilization to ensure that the investments already made are assured and that major reinvestments will not be required.
Look to identify those standards development organizations that are widely represented and have successfully implemented those standards to ensure the successful outcome of this subcommittee's recommendations.
The task before us all is formidable but not unobtainable. We must clearly understand what is already in place and define what our objectives are. This is complicated by the dynamics of the various health care market segments. Once stated timelines can be established that will have the least impact upon current lines of business, while minimizing development and implementation costs. In this way, our mutual goal of exchanging information across all segments of health care will ensure maximum patient outcomes and ultimately the reduction in health care costs at the highest possible quality to the patient. Thank you. I think we're ready to get your questions because I'm sure there are many.
MR. MOORE: I was waiting for you guys to go.
DR. LUMPKIN: I've got questions as always, but --
MR. MOORE: I guess this is to Kepa and the clarification of the differentiation between a service bureau and a clearinghouse and the adoption of standards. I'm one of those HCFA people who had a false impression.
[Laughter.]
The clearinghouse really facilitated the movement of that data from point A to point B, and the many formats that had existed between a payer and a provider which were hundreds today, where the service bureau primarily was focused back to the provider to provide reports, documentation, follow-up, et cetera and the clearinghouse could be a service bureau also, but clearing that distinction. The development of single standards in these transaction sets, what does that -- does that help with that whole process? Does that allow the provider to get closer to the payer and the payer to be closer to the provider in the communications link between the two if we have standards, removing some of that infrastructure that we saw that you had there, Kepa.
I'm not saying we want to get rid of clearinghouses, I'm just saying we need to find a way to get what moves electronically. What happens down in the provider world and what happens down in the payer world is there after it gets in the front door, but moving it from one front door to another front door in a standard way so I can deal with every payer, if I'm a provider, and if I'm a payer, I can deal with multiple providers or their representative, be it a service bureau.
DR. ZUBELDIA: The service bureau is acting as the back office for the provider. If the provider is using the service bureau, the provider couldn't care less if there are standards or not, because he is going to give a piece of paper to the service bureau and the service bureau employees are going to key that into their computer and generate a transaction. If there is not a service bureau and the provider is handling the back office tasks himself or herself, standards will get them much closer to the payer. It will get them closer because there will be more standard transactions to use, rather than because they can connect directly to the payers.
In a doctor's office, if they want to connect directly to the payers, what they have to do today is sign an EDI agreement between each one of the doctors and Medicare B, sign another EDI agreement between each one of the doctors and Medicaid, another EDI agreement between each one of the doctors and Railroad Medicare, and another EDI agreement between the back office office manager and the clearinghouse for the rest of the world.
Did I answer? Standards will help. It's just technology. We have standards in place, many of them, a lot of them to choose from, and going to one standard will help. MR. MOORE: But one standard, and this goes back to the other part of your statement where you said that your reading of the law says that we can -- I read what you said, that we would continue business as usual. That's not the way I've been reading it, nor some of us here, and my reading of it is that if you're a payer or a clearinghouse or one of those other entities, that you must use the standard, you don't have an option. If you're a provider, if you want to deal in electronic business, you must use the standard, and if you don't use the standard, you can deal in paper.
DR. ZUBELDIA: I hope that's the reading.
MR. MOORE: I don't know if that's -- Bill?
DR. BRAITHWAITE: That's how I read it too.
MR. MOORE: And that's how our OGC reads it.
DR. ZUBELDIA: I had conversations with payers last week in California and a couple of them said no, we want to have our own EDI through the Internet with our own Web pages with our own standards. As long as we also support X12, we can have our own stuff.
MR. MOORE: And I've had payers tell me that if they knew that we were going to make this read of the legislation, they would have never supported it. I can understand that, because that eliminates a part of the business on their side. But if we were going to go with the legislation with the intent of it I think, that wasn't the intent. The intent was to standardize certain financial transactions, standardize unique identifiers, standardize security, and standardize the rules under which we all play.
DR. LUMPKIN: But let's take it one step further. The purpose was to simplify.
MR. MOORE: Right.
DR. LUMPKIN: You can't simplify if you allow everybody to set their own standards. That's the issue. If you have a managed care plan that is a staff model, and everybody is operating within that environment, that's one issue, and that will get us to the question that I wanted to pose which is Kathy's question earlier, what does capitation do to this system where you no longer are exchanging information for the purpose of billing. What does that do to your members?
MR. CURTIS: With capitation, you're really looking at a modified version of a claim and what we're calling an encounter, whereas you would still collect the basic information that's necessary to make a record that a patient did come in for treatment at a physician's office or within a hospital. The insurance company, or the managed care entity still needs to keep track of that information, and in most cases, they will need to have additional information which brings us to the subject of attachments and the process of authorizations, referrals, eligibility and then you go into which standards are in place.
But backing up to the conference that we were in attendance about two weeks ago regarding standards, there's a lot of discussion regarding the use of standards and which standards should actually be used, but also we need to look at what is the process that these standards are being used to fulfill. There's a saying in computer lingo, FIFO, first in first out, and also garbage in garbage out. Sometimes if we take a disorganized process and computerize it, all you have is an electronic disorganized process. So this is a tremendous opportunity for us to step back, look at the process first, then look at what are the measures that we need to accomplish a more simplified process. If one of those measures happens to be implementation of standards, or standard sets, then I think that that's where we should be moving. I think we're all moving in the right direction, but there's a little bit of confusion as far as applicability, as far as which provisions are under the law, as well as what standards should actually be used.
DR. ZUBELDIA: Let me address that from a little technical perspective. I may be answering one of your previous questions if there was something to be added to the encounter form what would it be. I think that standards will help the encounter reporting if going with X12 in that we can add encounter information to an X12 claim without burdening it with a lot of data maintenance. In fact, it's already there.
Some of the other non-standard formats would require a lot of maintenance to add encounter information. As to what to add there, maybe adding a little bit of clinical information, enough for the people that were in the previous panel to do their work, for instance some outcome reporting. You could add to the encounter information the fact that there were three prescriptions given to this patient and these are the prescriptions. Whether the patient fills the prescription or not, that's another story, that's a bigger problem. You could add the fact that there was some lab work ordered or that the patient was discharged after the three stitches, or that the patient will be followed up and there will be subsequent claims or subsequent encounter reported for that patient. A little bit of clinical information I think would be perfectly appropriate and let's start looking at the encounter not as a claim minus dollars, but as a real physician to patient encounter or hospital to patient encounter.
MR. SCOTT: The only comment I would make is we hear that capitation issue a lot. In the image world of capitation, I'm a capitated managed care company and I give Dr. Jones $10,000 and say here's your list of patients, that's it, you take care of them, don't spend another dime and we don't have to talk to each other. That isn't the real world. That's capitation I think by some people's minds, you're capitated now, walk away from each other. We are going to report back and forth on what's being done, the utilization of resources. We tend to define resources with dollars sometimes in our society but we may change that a little bit.
I know most, speaking again for my own company but for other companies in AFEHCT as well, most of us are looking at that kind of value-added service to get away from the concept of a value-added network which goes to the data that we already have. Some of the things Kepa was just mentioning, we may already be picking up via other mechanisms that are not necessarily part of say the UB92 or the HCFA 1500 claim form that's now standardized in that process and doing these kinds of management services for our clients. Those are value-added services that clearinghouses are providing because they recognize that. Now whether that becomes standardized, these value-added services become routine and packaged, I think that's a very real possibility as we move forward and the committee ought to be looking at that.
DR. LUMPKIN: Let me ask one question sort of taking in your testimony. I heard one recommendation that we use NCPDP. I heard a lot of concerns about standards that we might be adopting and their impact. Suppose you were in our seats, what standards would you adopt? What standards would you see as problematic for what you're proposing doing in the future of your business?
DR. ZUBELDIA: Could you clarify as adopt as an adopted child or as the only child?
[Laughter.]
DR. LUMPKIN: Well --
MR. MOORE: Let's use my definition, it would be the standard, it would be the only child.
DR. LUMPKIN: It would be the standard. You can mix and match, but what I'm trying to get a feel for, as I hear some misgivings, are the SDOs that we by law are required to look at, are they problematic? I heard part of your testimony that you've been there from the beginning, but are they moving in the direction that's going to create barriers or is your concern, as I heard Jeanne Scott say, we're concerned if you adopt a standard other than NCPDP.
MR. SCOTT: For the pharmacy industry.
DR. LUMPKIN: For the pharmacy industry, yes.
MR. SCOTT: That's correct. I would have no problem with adopting, because I also represent the hospital and physician component products as well. The concern we have on that is that be that the transaction standard as against the other ANSI X12 type standards that are routinely bantered around in terms of authorizations and the eligibility inquiries and status inquiry standards I think those apply across the board.
I think probably where the issue has started to cloud, and it's not just the pharmacy industry, it's within the hospital and with others as well, is the 837 and the existing validity of say the national standard format or the electronic version of the UB92 and picking and choosing in that area and saying everyone is going to use say the 837. That is problematic, it's problematic for the pharmacy industry because it would have to change an existing standard that is functioning very effectively and very cost efficiently and is universally accepted with the pharmacy industry.
DR. LUMPKIN: Okay, I'm sorry, I may have misunderstood. So if you use NCPDP and carve out that portion of 837 that overlaps and is not compatible, then is that a problem?
DR. ZUBELDIA: From our perspective we don't care, because we use all of them now. We have 837, we have 835, we have SF, UB92, proprietary everything, so we don't care. The 837 brings some efficiencies in that the size of the transactions is smaller, the communications cost is lower and going to a standard implementation guide is much easier with the 837, expandability is much better with the 837.
Looking into the future is the way to go. I firmly believe that X12 is much more useful for us than any of the other flat file standards, and we will have more transactions to choose from if we go that route than if we go with other flat file standards. But to tell you the truth, it really doesn't matter, it's a minor issue in the amount of complexity we're dealing with.
MR. CURTIS: Also from our industry's perspective, following up on what Kepa has said, when you look at which standard to use, you may want to consider what segment of the industry are you really utilizing that standard, or do you intend for that standard to be used. The pharmacy has its own set, as Jeanne said, which has been functional. We really don't see a need to go back and reinvent the wheel. There may be some modifications that may be required.
But also when you look at standards, look at who is using those standards. When you look at some of the other industries that have been compared to our industry such as the banking industry, for instance, Chase Manhattan is the largest financial institution processing ACHs or accredited clearinghouse transactions for the financial. When they made a decision, or even let's say General Motors makes a decision that if you want to do business with us, then you will connect to us via this protocol, you will use this transaction set, by golly everyone who wants to do business with them will actually be using those protocols and those transaction sets.
What we have before us today is in reality, HCFA is the largest payer in the country, they represent a significant amount of revenue for physicians and hospitals. So whatever decision they decide or whichever protocol, whichever standard they decide upon will be used and it will become by de facto the standard for the industry because those physicians and hospitals represent revenue for our companies. We must look at what are the business needs of our clients as well as our ability to remain competitive in the industry. As long as those standards are going to be used by various entities that represent a significant portion of revenue for those entities, we're going to adhere to whichever transaction set is out there.
What we would like to see is a little bit more open use of those standards as far as when Kepa was saying the 837 or the 835, and you have the 270, 271. All those transaction sets are currently in use in some form or by various entities right now, but they really haven't been used to the great multitude of payers as well as the other clearinghouses that service other clearinghouses or other payer organizations.
DR. LUMPKIN: Let me say that on HCFA's part, as I understand the process that's going on within HHS, they have agree that they are not going it alone. So this is a process that's going to involve many players within the Administration in trying to come resolution.
My difficulty is, and I'm not going to put you on the spot here, but I think it would be useful to us as we go through a very rapid time frame, if you were to say we can live with this, we can't live with that, and to be very specific. Saying that we can live with most of 837 but don't throw out NCPDP, that's very important for us to hear. If you say there are other components where you say you want them to be more open, we need to understand what that means, because we're going to need in some 12 months to be at a very specific point where we're going to say this is it.
MR. CURTIS: Those are the type of conversations that we've already begun to hold with HCFA, to make them aware that this is what we indeed support and also these are the players that will be responsible for implementing this. Please understand this is the impact you will have on our industry if moving within the same direction. It's not our intent to tell HCFA well this is what you must use because this is going to be advantageous to us. We're looking at it from the perspective that these are the issues and these are the transaction standards that we would like to have further developed because it will promote an expanded use of EDI in our industry.
DR. ZUBELDIA: Let me kind of put myself on the spot here. My company and myself, I've been participating with X12 even before X12 existed, when we had the meetings in the hallway under the auspices of the Finance Subcommittee and we were kind of the off group working on claims. NEIC back in 1982 started something called the MCDS format and HCDS format. Both were precursors to the UB82 electronic format and to the NSF electronic format. Ninety percent or 95 percent of the commercial claims were filed using our proprietary formats, MCDS and HCDS.
Last year, we decided to change directions and not encourage our proprietary formats any more and go with standards. Now for any new submitters they have two choices. NSF or UB82, UB92 electronic standard or 837. Today, less than five percent of our claims come to us as 837. About 90 percent of our claims go out as 837. We would like to see a movement where all of the claims come to us as 837 and all the claims go out as 837 and stop this translation nonsense. But the real world today is NSF and UB92 based and there is a dilemma here. We understand that going to X12 will be a great solution not only for us but for everybody else. The question is how do we convince all those providers to send X12 transactions rather than flat files.
MR. MOORE: I have that same question too because HCFA can take either of those, including the 837, at least our contractors have been paid to make the adjustments to take them. And my concern is not the acceptability of the 837 as much as it is the provider's capability to submit. Now, you all have sat here and said how you helped the providers in order to do this. Whether you're running a clearinghouse or you're working a service bureau, et cetera, you're taking information in one format and converting it to the other format. Is it easier for the provider to give it to you in a non-837 format, something coming out of his operation that's organized differently. I don't care what you call it, flat file, whatever, but it's information that he needs to get out of his operation to someone else to convert into a claim so he can be paid.
DR. ZUBELDIA: A substantial amount of the claims comes to us in what we call print pool(?) format. What they would print on a paper claim and they take that print pool file and send it to us. We translate it into whatever the payer needs. If it's a commercial payer, we put it on 837 most likely. If it's Medicare we put it in NSF.
MR. MOORE: Why do you put it in NSF if carriers will take it already in 837?
DR. ZUBELDIA: Because they don't. We can talk about this another time.
[Laughter.]
We can talk about it off line.
MR. MOORE: But I pay them.
DR. ZUBELDIA: I know, get a refund.
[Laughter.]
DR. LUMPKIN: Let me clarify what you're saying because this is going to be important and may lead to some questions we have with our panel after lunch. Are you saying that the software -- because the assumption is if we're getting it in electronic format, it's going through somebody's software. By and large the software is giving you principal and it's not giving you an 837 or any other format other than principal. The software that's out there and being used by providers.
DR. ZUBELDIA: The software, the large software vendors will give us either NSF, 837, whatever they want because they have that kind of control. Smaller software vendors are overwhelmed with changes in other health care issues, especially managed care and don't have the time to mess with it. Unless we provide incentives for them to do it, they're probably not going to do much about it.
DR. LUMPKIN: Just so I'm understanding the issue that you have a provider who converts the information, the data into an electronic format. Then that electronic format, which is whatever software that they're using, then transmits it to you. So that the differences we're talking about really are transparent to the provider and are related to how their information that they're entering into their system is converted into electronic means.
DR. ZUBELDIA: That's correct. They're in the hands of the vendors. Very few providers have their own software that they've written or their nephew has written. Most of them --
[Laughter.]
Most of them are in the hands of the vendors. If the change to a standard transaction is going to cause them $2,000 they're probably not going to do it because that's not their main function. Their main function is not to satisfy the payer, the main function is to take care of the patient. If the payer wants a different format, then maybe the payer wants to pay for the $2,000 conversion.
MR. CURTIS: I was going to pick up on what Kepa said. The focus of most providers is health care, not systems. Even though you may have some large hospital institutions that may have their own DP shops, that may develop their own home grown software, still the emphasis is on providing health care. Whenever you have to implement a change, we're kind of reluctant to change, we as humans in general. It's always a cost associated with that change. If the software vendor has the responsibility of providing the functionality to get standard information from the provider's desktop to the payer organization, I'm sure that they are capable of doing it. However, if there's a cost that they have to pass on to meet that functionality, the provider will be asked to pick up that cost and then the provider will say well hey, is it really worth my interest for me to invest in this change.
DR. LUMPKIN: But to the extent that we're looking at simplification and just having spent the last three or four months working with my wife who is trying to get a new information system in her office, which is a nightmare and continues to be one, the clinician really has no criteria on which to establish the selection of a system. So to the extent that we have some standard formats which would be the output that would be expected, you give some assistance to individual clinicians who are making substantial investments in information systems that may not meet the standard.
So to the extent that we can, that's part of the time pressure that we feel as a committee as well as under the legislation is that if there is going to be a rapid automation of the office, then there needs to be some criteria in which systems are selected and in which vendors operate.
DR. BRAITHWAITE: I had two questions. One was the fact that if the software vendors have only one standard to write to, that is the standard that HHS ends up adopting, should it cost the providers $2,000 to come up with this conversion, or will now all the office systems be written to that one standard? That's the first question I have of you.
The second is, and I've heard this before but it baffles me, that you put out 90 percent of your transactions, Kepa, in 837 format, but the 800 pound, I'm sorry 600 pound gorilla now of HCFA has contractors out there who have been paid to accept 837 but they can't? There's something wrong here.
DR. ZUBELDIA: Yes, we've been saying that for a long time. They cannot generate 835s correctly either. But since we have no recourse in that, we take it, we fix it and send it to our providers.
MR. CURTIS: See, what you're really talking about is translation facility and that's a tremendous opportunity for businesses to take part in. It's a significant amount of revenue for a lot of companies. I'm a former NEICer and I did a lot of the translation there, so you see it as a way to gain a competitive advantage also by offering this service. I don't believe that there are going to be too many companies that are going to move away from providing this facility. Speaking from my company's perspective, THINC will be providing translation capabilities, as well as adhering to the standards, because simply it's a question of getting the business and making sure that our clients are meeting all the necessary provisions of the law.
DR. BRAITHWAITE: The new law says that all payers must accept the standard transaction if somebody wants to send it to them. Are you going to want to send it to them?
DR. ZUBELDIA: Yes, if they can take it.
DR. BRAITHWAITE: They have to take it by law.
MR. SCOTT: HCFA says they've got to take them and they can't now.
DR. ZUBELDIA: The fact is that if I want to bring up the 837 with a Medicare carrier, it's going to take me about three to six months of dealing with them because their translator is not translating it correctly and because they really haven't had much experience with it. I have to teach them how the 837 works. I don't need to go through that kind of pain, I have other things to do. So I just bring it up with NSF. Now, they claim they can't take the 837. That's why I'm so concerned about this adopted child we're creating, because everybody is going to claim they can take the standard. Who is there as the standards police to tell them you're not taking the standard?
MR. MOORE: There must be something wrong here because I heard Mr. Curtis say that an 837 required no implementation guide -- or you said it did require an implementation guide. We had in a previous session back last month one of the TPAs sit here and say it took him a year to implement the 837 because he didn't know what the hell was going on or how he was working with it and there was no one to help him with it. After a year of working with it, he understood it more. Is this something we're going to have to go through with every payer and every provider in the country with the 837? And the only ones who know how to do it are the vendors, that is the clearinghouses. I mean there's something wrong here when we got -- you said that the vendors are the predominant players at X12 -- there is something wrong here when both sides of the house that want to communicate can't understand what the standard is but the people who said it in X12 know it best.
DR. BRAITHWAITE: And X12 says it doesn't need an implementation guide by the way.
MR. MOORE: Right, that's what they said in their documentation.
DR. BRAITHWAITE: Tell us what's wrong here and how to fix it.
DR. ZUBELDIA: I think it needs some implementation guide. I think one of the problems that HCFA is facing there is that --
MR. MOORE: It's the Department now, it's not just HCFA.
DR. ZUBELDIA: Okay. One of the problems is the lack of training in X12 by the people that are actually implementing it. Another one of the problems is because of the way they do business, instead of buying a commercial translator, most of them have written their own programs. You may save a few pennies by writing your own program at first, but then it doesn't work. Then that's a very big expense for everybody else.
So I think if the HCFA carrier intermediaries were required to use a commercial translator, we would see a mass migration to the 837. If HCFA would put out a standard translation for the 837 where all the carriers or intermediaries have the same translation, we would have no problems. Right now, because each one of them has written their own little program, each one of them has different requirements. The implementation guide is something that they kind of follow but you talk to them and they say well, we don't follow that part and that little part they don't follow is a problem.
MR. BLASZCYNSKI: It's kind of interesting, I'm sitting here very much like what we do out in the industry as a VAN where we're in the waiting room listening to everybody going in to talk to the Director of Complaints. We listen to the complaint out in the waiting room because they needed somebody to talk to. I can empathize here with the rest of my cohorts in that standards are standards only if they're truly implemented totally as a standard.
One of the communications we get constantly is well, you can get me connected to multiple payers, but can you guarantee that they will all take my transmission the same way. The answer is obviously not because they're your trading partner and it's between you and then as to how you're going to communicate the data. I can get it to you, I can get it to them, it doesn't matter, but what is inside the envelope is key. If you do not have a complete standard with a complete standard implementation that everybody comes to an agreement with, we're only going to fix part of the problem.
There's too many insurance carriers involved here, there's too many intermediaries involved who will be looking at the data differently, even though the data is within the standard and maybe every field is proper within that transaction, unless everybody agrees to take that data and use it the same way off of the same format, we're going to be beating around the bush a long time. We will be gainfully employed for a long time doing edits and formats. We will bring simplification to it and I think it will be a piece of the puzzle. There will still be different usages of that data, there will still be different requirements to take that data and do something whether it's an edit or a format for reporting outcomes analysis, et cetera.
Back to your question, Dr. Lumpkin, the standard sets have been identified in the Act, our key standards. What we hear from the provider side of the puzzle and the payer side of the puzzle is that they do want eligibility. We do want enrollment data, we do want remittance advice, we do need to submit the claim. What drives the provider is payment of the claim. It's simple, he's got to stay in business. So that's very important. Is the person eligible in the plan before I render services? If he isn't, and he walks out of this office without a payment, well so be it. I don't know where I get reimbursed for that, but somebody is going to wind up having to pay it and it's really society in general.
So there's a very key requirement to get down to accepting the standards that were listed, identifying them across the continuum, looking at the implementation guide so we don't have multiple implementation guides that are just going to confuse the issue. I think these two have to go hand in hand. Then in fact, let it up to the dynamics of the industry between the provider as a trading partner, a clearinghouse, a TPA, a third party biller, whatever, and the payers to determine how else they're going to use that data. It's going to simplify things for them because they will know in fact that it's reported under a single methodology, it's implemented under a single methodology and this is going to be a great enhancement.
So as I think you're hearing here, we all are absolutely supporting the standards, it's going to simplify some of our businesses quite a bit. It is not going to put these organizations out of business. We will still be bringing value-added services to the provider community. But again, I think Kepa's point is that even though we talk standards, it's not being practiced out there.
DR. ZUBELDIA: Let me make a suggestion here. This is something that I've talked to Bob(?) in the past at HCFA. The creation of a standards police, although it sounds kind of funny, would be useful. If there was out there a reference standard, like a reference implementation of the 837 against which anybody that receives 837s can download from the net this reference implementation, and if they can process it, they can say I can receive 837s. That would be very useful. If there was a place in their computer where they could program an entity or some place where you can send the 837s that you're generating and say could you check this for me and they check it and give you a certificate that that 837 complies with the implementation guide, not with the standard, with the implementation guide in all respects, and you take that certificate and with that certificate you can go and show it and say see, my 837 is acceptable, now all I have to do is sign here and I can send it to you. That would be useful.
If you do that for all the transactions, create a reference implementation and a compliance verification center, that would promote the actual use of the standards. The situation we have today is that as a clearinghouse not only we have to test with each one of the carriers our 837s, but every time we bring up a provider even though we're sending 837s to Medicare of Texas, every time we bring up a provider in Texas, we have to test again. That's nonsense.
DR. BRAITHWAITE: Do you think this is a role for EHCNAC?
DR. ZUBELDIA: It could be.
DR. BRAITHWAITE: Clearly if this organization is going to certify clearinghouses in their ability to do this, why not be able to provide that service to payers and providers?
DR. ZUBELDIA: As an EHCNAC commissioner, I brought it to the commission several times. The consensus is who would use it, because if there is not a direction to use it, everybody wants to have their own little twist so they don't want to have that. But I think it would be a great role for EHCNAC, accreditation not only of clearinghouses, accreditation of EDI trading partners.
MR. CURTIS: I think when we first formed EHCNAC, the concern was well, this is great what we're doing but who is really going to use this, what incentives will be there for us to serve this function? I think that by virtue of this legislation, there's clearly an incentive for people to take advantage of the services that EHCNAC does offer.
DR. LUMPKIN: Okay, we're out of time. Are there any burning questions from the panel?
I would like to thank you very much. It's been very helpful. I'm sorry if we made you a little bit uncomfortable in trying to put you on the spot, but we have a very important task and we appreciate your input. I encourage you to submit further comments or thoughts that you have in writing to us because we will be looking at them very closely.
DR. BRAITHWAITE: And electronically please.
DR. LUMPKIN: Electronically too so we can post them on the bulletin board. We will be back at 1:30.
[Whereupon the meeting recessed for lunch, to reconvene at 1:30 p.m.]
A F T E R N O O N S E S S I O N
DR. LUMPKIN: While you're taking your seats, there is a fax sheet on the Health Insurance Portability Act on Administrative Simplification. It gives a little bit of background and the process that HHS is following to implement that. That will be available on the Web site in the very near future, the next day or so. Let me put it this way, it's available as soon as you look for it.
Okay, we have quite a full panel. As you heard earlier in the day, those of you who were here, there will be a number of questions, so I'm going to ask each panel member to adhere as closely as possible to the five to seven minute time frame.
MR. CARLSON: My name is David Carlson. I am Executive Vice President and co-founder of Enterprise Systems. I want to thank you for the opportunity to appear before this subcommittee to answer the four questions regarding the implementation of the Administrative Simplification subtitle of HIPAA.
To help understand my perspectives on this topic, I will provide a short background of my company and myself and then answer the questions.
Founded in 1981, Enterprise Systems is a public health care information services company that develops, markets and services an integrated suite of application software products to assist health care providers in managing their operations. These operational information systems, which are sold primarily to acute care hospitals, focus on cost containment and address a broad range of non-clinical management needs, including material management, operating room logistics and financial management and patient scheduling. ESI's products operate on personal computers, networks and make extensive use of electronic data interchange. In 1995, ESI did over $33 million in sales and ranks in the top 20 of health care information system vendors.
Today, ESI's products operate in over 1,000 health care organizations throughout the U.S. and Canada. Each of these installations has dozens of EDI interfaces for patient billing, electronic commerce, purchasing, and using HL7 along with the National Council for Prescription Drug Programs, NCPDP and X12 standards.
As chief systems architect of ESI's products, I have promoted the use of EDI standards as part of our software solution. In fact, we were the first software vendor to implement X12 purchasing EDI in health care and I was personally one of the founders of HL7 standard. I have also served on HL7's Executive Committee for six years as Chair-Elect, Chair and currently as past Chair.
My response to the questions. What are your organization's expectations for the results of the Act and in what ways will the outcome affect the members of your organization, both positively and negatively?
The software systems we provide are but a few of the many health care organizations, such as hospitals use to manage their business. These systems must integrate in order to eliminate duplicate data entry as well as consolidate data for administrative and clinical purposes. EDI standards reduce the cost of this integration in terms of development, implementation and support. At this point in time, we believe there exist many useful health care EDI standards. More importantly, we believe there exists adequate standards developing organizations like HL7, NCPDP and X12.
As a vendor, we have realized significant savings by using EDI standards and we pass these savings on to our customers. These savings are fully realized when all the vendor systems use the same standards. Because each vendor is free to adopt standards according to their own timetables, causes ESI to modify or customize those interfaces. Ultimately, this customization is paid by the health care organization.
By adopting existing industry standards and mandating their use within a specific time frame, the Secretary will eliminate this customization and associated additional cost.
We expect that in the short run this will cost health care organizations a small investment to upgrade their systems with these standards, but the overall savings will far outweigh this cost. Also, it should be noted that most organizations are planning for a much more significant upgrade to their financial administrative systems to address the year 2000 issues.
Number two, does your organization have any concerns about the process being undertaken by the Department to carry out the Administrative Simplification Act requirement of this law? If so, what are those concerns and what suggestions do you have for improvement?
ESI's main concern is that we are unclear about the decision making process used for choosing the EDI standards. In some areas of the health care business, it is possible to use different standards to accomplish the same EDI objective. If one standard is mandated over another, it could disenfranchise important health care constituencies. ESI suggests documenting the decision process will help all groups understand the intent with the resolution.
Number three, what major problems are experienced by members of your organization with the current transactions specified under the HIPAA? For generators of the data, how readily available is this information that you need to provide for the transactions and how meaningful is that information from a clinical perspective? For the users of the data, are you receiving the information you need from the transactions to pay the bill, manage the care process, et cetera? What is your perception of its quality?
Users of our systems generate data. As noted above, when integrating, we often encounter vendors that do not comply with EDI standards. For example, they could have proprietary data formats, missing data, proprietary codes and vocabulary or perhaps customized syntax. In these situations, we are forced to customize our standard interfaces which mean costly custom design, development, documentation, implementation and support. While this is better than developing a completely new interface, it would be much more cost effective to not change the standard interface at all.
And four, how can the goal of administrative simplification best be achieved while meeting the business needs of the stakeholders?
There are three suggestions to help make the legislation a success. First, the selection of the standards must be clear, unambiguous as to implementation date and with no loopholes. That is, it must apply equally to all health care groups, including the government in all areas of the United States.
Second, where no standards exist for specific transactions, the standards developing organization with the best domain experience should be encouraged to develop one.
And finally, from working with HL7 and other standards group shows that no one standard could possibly address all the EDI needs of health care. The American National Standards Institute has recognized this through its formation of the Health Care Information Standards Board. The main purpose of this board is to coordinate health care standards. Part of its work effort includes catalog and registration of standards. ESI suggests the Secretary use and support this group in order to promote EDI compliance through education, implementation examples, as well as arbitrating coordination issues. Thank you.
MS. HAMBY: Mr. Chairman, members of the committee, I am Pat Hamby, Corporate Director of Regulatory Affairs and Standards for HBO and Company. With me is Chuck Meyer, who is HBOC's Informatics Standards Liaison and he will help and assist in responding to some of your concerns on the information systems. We appreciate your invitation to address the subcommittee surrounding the implementation of this important piece of legislation.
HBO and Company serves the financial and clinical information system needs of the health care enterprise worldwide, inclusive of integrated health systems, managed care organizations, physician enterprises, home health agencies, long-term care facilities and hospitals.
I hope our responses to the questions posed in the invitation serve to further the goals and the objectives of the committee. The underlying theme, I think, that you will find throughout all of our responses is uniformity, uniformity in the area of data, interpretation, as well as implementation.
With response to question one where you ask what is our organization's expectations, what are the outcomes both positively and negatively that we anticipate, of those transaction sets or the information that's listed in the particular piece of legislation what ranks priority and why did we choose that.
We are optimistic that the legislation will ultimately produce a consistent structure, data set and process model for the transaction sets defined in this particular subtitle. This will allow system vendors to concentrate their technical resources on the process of creating easily implemented, highly functional, user friendly financial systems. We expect both the provider and the payers will more readily accept and participate in electronic claims submission given the availability of a definitive standard.
It is expected that the implementation of the Act's administrative simplification provisions will result in significant savings in administrative costs. Any amount saved to administer health care can then be turned back into patient care.
A study commissioned by HFMA, or Health Care Financial Management Association, I think you've already received a copy of that last time, projected the administrative cost savings potential for a proposed piece of legislation in 1993 and indicated that the annual savings could be from $2.6 to $5.2 billion.
The premise of this particular proposal, of course, was that every health care entity would adopt electronic processes for common administrative procedures. Although HIPAA mandates the standard for those providers and payers who opt to process claims electronically, we feel that such substantial savings could well provide a financial incentive or a strong incentive for conversion to the electronic process.
With respect to priorities, some of the data elements necessary for a uniform data set can be found in the claims and payment transaction sets. Additionally, these transactions are the basis by which any health care entity or provider does business in health care today. In fact, they are critical to the provider's financial survival.
Standardization of these two key transaction sets would reduce significant or costly programming fees. Today, the industry continues to use hundreds of versions of the UB92, the HCFA 1500 and even the X12 837 and 835, thereby negating any benefit of uniformity. This loss of uniformity is costly to the industry and quite counterproductive.
From a vendor's perspective, given the transaction sets defined in the Act, the initial focus should be the process of health care claims submissions, processing, adjudication and remittance. The rapid growth of managed care organizations also provides the impetus for adopting a standard for plan enrollment, eligibility verification and referral certification and authorization. These transactions are critical in establishing the population being serviced by the health care enterprise. The remaining transactions can then take a somewhat lower position on the list of requirements, albeit it still important to the process.
Again, the key to success of administrative simplification is uniform interpretation and definitively stated standardization across all payers in the industry.
Special attention is necessary in the area of implementation process of these standards. Assurances that everyone understands the instructions for implementation in the same way is critical. In addition to the lack of uniformity in data requirements among the various payers, software vendors are required to handle the different interpretations of instructions across payers. For instance today, instructions from HCFA are often the same across intermediaries and carriers, however there are several different interpretations of those instructions. This generally means additional programming for the vendor and often times additional expenses to the provider.
With question two you ask about our concerns of the process being undertaken, if we had concerns what were they and suggestions that we had for improvement.
Soliciting input from a cross section of the industry affected by the passage of this legislation is an excellent first step. In our testimonies given, we've hopefully adequately expressed to you the concerns that assuring implementation of the Act will be done in the most effective manner. Input from the industry should provide you a glimpse into the world of providers, consumers, standard development organizations, payers, software vendors and the like, providing you with a better understanding of the impact this legislation will have on our world.
This will not be an easy piece of legislation to put into place, especially realizing that you're having to deal with today's marketplace, as well as determining what's going to envision -- your vision in anticipation of where the health care is heading.
We do have some concerns however. Although NCVHS is attempting to consult representatives of the full spectrum of the health care environment, we don't see this activity within other agencies. It must be fully recognized that those of us who provide software solutions to health care providers should maintain ongoing dialogue with you and with DHHS as you proceed to digest each aspect of this legislation. After all, we're the ones that most of the providers in the health care industry are going to turn to for implementation.
There is also some concern that the tenants of administrative simplification provisions within the Act may be prematurely extended into the areas of clinical transactions and computer based patient records. As mentioned this morning by Dr. Buck, it's imperative that these critical areas be accorded the same consideration as is being allocated to administrative and financial data. In our opinion, the standards in these areas are probably even more complex than those as defined in the financial and administrative ones.
With respect to suggestions, one component of credibility for a standard is determined by its proliferation within the industry. Even though a significant number of transactions addressed by the Act have already been defined by ASC X12, this should not be construed to mean that X12 is the definitive standard for all administrative and financial data. For example, in the area of claims processing, as you've heard discussion on this already, few organizations either send or accept ASC X12 format for claims submission. A vast majority of electronic claims are currently being processed via flat files in the version four or else in the case of professional fees NSF. These have been proven, widely accepted formats which with their wide acceptance increases the probability that the Secretary may well adopt a hybrid standard inclusion of X12 as well as other standards in the market.
This is not to say or not to mean that we are implying X12 should not be used for claims process. We do believe that as improved standards and processes become available, they should be adopted. Again, as pointed out earlier this morning, carefully assess what has been proven in the marketplace and as a software company we can virtually program anything, just tell us what it is that you want us to program.
HBOC does support the creation of a definitive standard data set, however we do not necessarily support the concept that a data set represents the data elements which must be sent in order to be in compliance with the standard. In other words, not every element within the data set should have to be sent with each and every transaction, allowing the payer to ignore those that are not necessary for processing. The concept that some SDOs have developed to accommodate a comprehensive data set or model should be considered. Under this concept, the data set is coupled to an interaction model and a hierarchial message description to create messages in a variety of formats. This approach to developing a standard shows technological innovation and incorporates the principles of object oriented technology. We believe this functionality is deserving of extensive analysis and evaluation as the national standards expand into the clinical areas.
With question three, you ask about problems experienced by members of our organization and also the perception of quality. Our customers are plagued by the lack of uniformity within the uniform billing process. For example, although the UB92 claim form itself represents a standard, there is little or no continuity in the usage of the data, the definitions of required fields, or even acceptable code values.
There is considerable variances from payer to payer. Those hospitals that due to location consistently treat and ultimately bill patients from surrounding states often times must maintain multiple billing applications. Each of these applications are tailored to specific state or intermediary configurations. There are also instances of significant variations between intermediaries within the same state.
The proliferation of versions and release levels of a given standard is also cause for concern. Subsequent versions of existing standard transactions are often materially different from the original. Further, there are rarely guidelines for conversion from one release to the next. Without compatibility within release levels, vendors must maintain multiple application releases to support each one of the various releases.
In addressing the issue of quality, it should be noted that regardless of how comprehensive a standard is, it will not affect the quality or perception of quality of the data being exchanged. A standard neither adds to nor detracts from the meaningfulness of clinical information. However, standards will lessen administrative burden and reduce costs in health care delivery and standards will also help to establish the basis for being able to define quality by allowing a comparative data for better direct medical care, research and quality improvements.
In terms of the goals for administrative simplification, how they can best be achieved, the goal can best be achieved by the use of uniformity and standardization. This will require a consensus process among all players. There needs to be a feedback loop from the industry to the Secretary to monitor how the implementation is proceeding. You today and currently are dealing with how administrative simplification can be implemented and you're doing this through public hearings and testimonies. Once the standards are adopted and implementation begins, there needs to be a process put into place that will monitor how is it working.
Specific constraints that must be considered include three things. One, the allowance for flexibility; secondly, timeliness for implementation; and thirdly, openness for technological innovation.
Allowances for flexibility should be considered due to the rapidly changing environment that the health care industry finds itself in today. Acquisitions, mergers, new laws, new technology are creating changes to the health care market at an alarming rate. What may make sense today can be obsolete three to five years from now.
Timeliness will be needed for implementation. Some type of mechanism should be put into place to respond to future system needs or requirements. Providers and payers, as well as vendors, need to have ample lead time for programming changes, education, as well as training.
Technological innovation is critical. It would seem counterproductive to mandate a standard that stifles technological innovation. The standards should be as comfortable in an object oriented environment on the desk top as it is in a complex networking environment like a CHIN. The modeling efforts underway, as I mentioned earlier, in several of the standard development organizations are moving in the right direction, if we are to derive a standard that will graciously move us into the future as technology continues to raise the bar within the health care enterprise.
As I mentioned at the beginning of the testimony, there should be three indicators or three themes in response to the question, that is uniformity in data, interpretation and in implementation. Thank you.
MR. BECKLEY: Good afternoon. I am Bob Beckley, Senior Vice President, External Affairs for PDX, Incorporated. PDX is the largest pharmacy software vendor in the United States. Approximately 9,500 pharmacies use our software to dispense about 20 percent of all prescriptions filled in the United States. Because I am a member of NCPDP, HL7, X12 and a participant of EDIFACT meetings for the last two years, the topic of standardization is of great concern to me. The recommendations that this committee makes will have a significant impact on my company and the pharmacies that we serve.
Your first question was what are your organization's expectations. We at PCX hope for and expect that this committee will recommend the continued use of current standards, joint development between standard development organizations for new standards, and coordinated initiatives for the creation of standard identifiers and security. I would like to expand on those three categories.
Current standards. Without argument, standard transaction sets are necessary to expand and enhance electronic communication capabilities between health care providers and payers. PDX believes that regardless of the standard's syntax of developing standard developing organization, enhancing one of the consensus built standards, which a significant percentage of the health care industry already uses, is far more beneficial to the health care industry because of the financial impact associated with developing, testing and implementing a new standard. I will go into more detail about that in a minute.
Therefore, we hope the subcommittee considers the following before making their recommendations on existing standards. Number one, is the standard current in use, is it ready for industry-wide implementation or under development? Is the standard working or is it a paper standard? If it is a working standard, to what degree is it being used within the health care industry? Is the SDO that developed and maintains this standard ANSI accredited? If not, do they follow ANSI guidelines for standards development? Does the SDO membership reflect the diversity of the business sector it represents and a commitment to develop standards that benefit the entire industry segment? Finally, does the standard meet the business needs of the organizations that are utilizing it?
The second part of the question was what negative impact could a standard have, or would your recommendations have. The one outcome that would have the greatest negative impact on the pharmacy services sector of health care would be changing the on-line electronic claims standards that pharmacies currently uses for approximately 70 percent of all prescriptions filled in the United States. The other 30 percent are cash flow prescriptions and are not transmitted to a third party for payment.
NCPDP's telecommunications standard has proven to be successful for over nine years by continually changing and growing with the pharmacy industry. Over 54,000 pharmacies, 90 payers, 43 state Medicaid agencies exchanged over one billion electronic claims for over 100 million patients in 1996 using this standard. Changing this standard would have a significant financial impact on the entire pharmacy services sector. Conservative estimates are over $200 million. For my company alone, changing this standard would involve over two years of just testing with all the different payers that we communicate with. In addition, all the time spent on changing to a new standard would prevent the pharmacy services sector from continuing to advance in other areas such as drug utilization review, patient education, disease management and electronic communication with other health care providers.
As far as new standards, in today's environment a single standards development organization cannot develop all the standards for health care. Therefore, PDX hopes that the various SDOs will join together in the development of new standards. As different sectors of the health care industry further development electronic communications between health care providers, coordination of effort will be crucial to the success of these new standards.
Standard identifiers and security. The standardization of identifiers will help accelerate the sharing of information between health care providers. Software vendors spend an inordinate amount of time creating programs that will store, cross reference, and convert the many identifiers that are attached to a single patient and health care provider. Along with the identifiers, we need to implement security measures that will protect the information without creating unnecessary bottlenecks that could prevent the efficient exchange of health care information.
Your second question was does your organization have any concerns about the process being undertaken. We are very pleased with the progress. We hope that you continue to utilize the expertise that is available with the standard development organizations, ANSI-HISB, WEDI and associations like the National Association of Chain Drug Stores, NCPA, APHA, which I believe APHA has already testified. Our only concern at this time is the exclusion of a pharmacy committee or organization in the Act for consultation before a standard can be adopted or modified.
Your third question, major problems, what major problems are experienced by members of your organization. The NCPDP standard for electronic claims meets our current needs. The standard has continued to evolve as our requirements have changed. In the areas of payment reconciliation and eligibility verification, our industry segment, has and is working with X12 to implement X12's batch standards in these areas. Because the pharmacy sector has been utilizing electronic claims for over nine years, this area is quite stable and not in need of major change.
Earlier today, there was discussion about clinical information. We recognized in the pharmacy area quite a few years ago that clinical information also needed to exchanged. In 1994, we passed a standard that allowed for the exchange of drug utilization review information between pharmacy and payers. I would like to expand on this just for a second to help you understand how this transaction works.
This is an on-line transaction. When a pharmacy sends a claim to a payer, with it goes clinical information about the drug and also information about other drugs that have been dispensed to the patient. When the payer receives it, they have a database of other information about this patient, diseases, allergies, other prescriptions and health care conditions. They respond back within the 20 seconds you heard earlier today, not only will they pay for this prescription, but are there any drug utilization review issues, are there any compliance issues, over utilization, under utilization, et cetera. So we already have started for the last two years passing clinical information back and forth.
Development of additional clinical standards will help improve the quality of health care by making critical data more easily available to health care providers.
Finally, your last question, how can the goal of administrative simplification be best achieved while meeting the business needs of all stakeholders. I think business needs is the key word here.
We can obtain the goal by continuing the current process of meeting with the different segments of the health care industry. Recommend standards that already have industry wide implementation and concentrate on the areas that have limited or fractured implementations. Because the many segments of health care have different business requirements, base decisions on industry segments, not health care in general.
To accelerate the process of joint development for new projects, establish procedures for SDOs to work together as equals. The work ANSI-HISB has started is to be commended, but we need more teeth.
Finally, make standard identifiers a top priority. The recommendation and rapid implementation of identifiers, like HCFA's NPI, is needed for the standardization of communication and data content between health care providers.
The standardization of health care transactions is formidable. All of the SDOs and trade associations can help you in this process. Please continue to use all the resources available to you, not just a select few. By continuing to follow the course you've started with these meetings, we feel that you will succeed. Thank you very much.
MR. KNAUS: Mr. Chairman and members of the committee, I appreciate having the opportunity to present this statement summarizing our views and concerns related to implementation of the administrative simplification components of HIPAA. My name is Gary Knaus. I am President and Chief Operating Officer of Context Software Systems, Incorporated, a privately held firm with offices in Illinois and Florida. Context specializes in providing technological solutions that address the coding, clinical editing, fee management and regulatory compliance challenges facing the health care industry. Our firm's products range from coding and clinical editing software programs designed to increase the likelihood that claims information submitted by providers is accurate and compensable to worker's compensation bill review software designed to help payers and third party administrators ensure that claims are paid according to state regulations. Context's 10,000 clients represent a broad spectrum of the health care industry from solo physician practices to the largest payers.
Context is actively involved in the Association for Electronic Health Care Transactions and in the International Billing Association, the latter for which I am a Special Advisor to the Board of Directors.
In response to your questions, first the expectations of results and the outcome. We anticipate that the impact of the standards requirements will be positive for our firm, for many other software vendors in the health information system industry and believe that in the long-term significant reductions in the costs associated with administering health care will be achieved.
Specific positive outcomes we envision include the transition from multiple to single standards will substantially reduce costs related to developing, implementing and maintaining software programs that facilitate electronic health care transactions. Cost reductions will be further enhanced by new software and hardware technologies being introduced into the health care market such as client server and Internet capable systems. These platforms are inherently more flexible and provide greater capabilities at a lower cost than the older legacy systems they replace or enhance.
Given the competitive nature of the HIS industry, a significant portion of these savings will ultimately be passed on to the software vendor's clients in the form of lower license fees, lower transaction costs, lower maintenance costs or lower development costs. Lower costs will stimulate more demand for electronic health care transactions while concurrently stimulating demand for software products that implement standards. In the process, standardization will become a competitive necessity for both software vendors and their clients alike.
We believe that standardization of electronic health care transactions will lead to an improvement in the quality of data being transmitted among industry stakeholders.
By contrast, we believe there will be less favorable short and mid-term impacts. They include a capital outlay for software, development, computer hardware and training needed to implement the standards will initially be greater than the savings resulting from standardization, leading to implementation delays especially for smaller and mid-sized firms. These firms typically have fewer resources and if forced to choose between allocating limited resources to implementing new standards, and activities that allow their businesses to perform basic functions, they are likely to choose the later.
Firms that handle a high volume of electronic transactions will benefit more directly than those handling fewer transactions. High volume firms have more transactions over which to recover implementation costs.
Development and implementation of new software programs invariably takes longer than anticipated. We do not believe that it will be possible for the industry to convert to the new standards within the 24 month time frame specified. This last issue we consider to be the highest priority for both our firm and our clients.
Regarding concerns about the process being undertaken, we are pleased that HHS is a actively soliciting the input of industry stakeholders.
The third question, major problems that are being experienced and how readily available is the information needed. With the occasional exception of first report of injury, our worker's compensation clients have elected not to implement transactions specified under HIPAA, including those which our product is logistically situated to handle. Such transactions include health claims, eligibility, attachments, claims status and referral and certification authorization. Also we are not aware of any initiatives currently underway by other vendors in this market segment to implement these transactions. I will discuss why we believe there has been a general lack of interest in these capabilities in the workers comp market when I address the next question.
Regarding the availability of data required to perform transactions, we have concerns related to the impact of the restrictive license terms and fees being imposed by the American Medical Association on the health care industry for use of CPT codes. HIS firms developing products which include CPT are being required to enter into lengthy and complex contracts with the AMA. These contractual requirements make it difficult for firms which incorporate CPT in their products to enter into normal and reasonable business agreements with the resellers, vendors and clients.
These terms not only impede the application of technology designed to lower health care administrative costs and improve quality of procedural data for use in clinical studies, they increase costs to the industry.
To illustrate how development is being impeded, vendors are currently prohibited by the AMA from creating a marketing Internet software applications that contain CPT. Development is further impeded and product costs further increased by the fact that vendors must shift valuable resources away from the design and development of products which better meet health care industry requirements to ensuring that all of its contracts and agreements fulfill the AMA's extensive CPT licensure terms.
Finally, there is another adverse consequence. CPT license fees may be imposed multiple times on the same end user. As an example, a physician practice could potentially pay separate license fees for use of CPT in its computerized patient record system in its coding software, in its clinical editing software, in its practice management system, in its fee management programs through how-to books it purchases to assist with coding and fees and through its purchase of one or more of the AMA's CPT books.
Your final question, the goal of administrative simplification, how can it best be achieved. In addition to the concerns I have already expressed, there are two factors we believe may further constrain implementation. First, the worker's compensation industry's EDI initiatives have been focused almost exclusively on first report of injury and meeting various state mandated EDI requirements. Why? The first report of injury transaction provides firms with timely information that is needed to initiate the case management process. The earlier the intervention of case management, the greater the savings, thus the market's recognition of the value of this transaction.
As to state EDI transactions, which typically involve sending either on tape, diskette or via modem, copies of the insurance claim or explanation of reimbursement, these functions are performed only because they are mandated. Firms handling worker's compensation bills must also manage complex state fee schedule rules, strict reporting guidelines and various state-specific managed care initiatives. Since these bill review firms are basically service companies, and compensated on a per bill or per line basis, there is little incentive or resources remaining after meeting all the state mandated requirements to implement other electronic transactions. Only the larger more resource rich firms that perform worker's compensation bill review functions are likely to implement these electronic transactions. Widespread implementation in this market is unlikely to take place as long as state-specific EDI requirements differ from those defined under HIPAA or until new technologies make such transactions cost effective.
Second, implementation of the administrative simplification standards requirements will coincide with system conversions and software reengineering activities dealing with what is often referred to as the year 2000 problem, that is the inability of a computer program to properly interpret the year 2000. Estimates of worldwide costs associated with reengineering software to eliminate this problem have been as high as one trillion dollars and estimates across the United States firms as low as a few hundred million dollars.
Although we are not aware of any HIS specific studies that address this issue, and it is unlikely that a firm having difficulties in this area would want to broadcast such information to the industry, we believe its impact has a potential to be substantial. Affected firms will divert resources away from other system implementation activities, such as administrative simplification standardization requirements, and apply them to addressing this complex problem which directly affects their ability to operate.
I would like to thank you again, Mr. Chairman and members of the committee, for being allowed to make this presentation. I look forward to answering your questions.
MR. FIELDING: Mr. Chairman, members of the committee, my name is Doug Fielding. I'm with MegaWest Systems. We are a practice management software vendor in Salt Lake City, Utah.
I will be begin by answering the four questions. The first question, on the expectations for the results of the administrative simplification standards, specifically on health identifiers. Health identifies for providers, health plans, and individuals are something that we have desperately needed for quite some time. We have already made strategic changes in our file structure in our system to accommodate these identifiers. The implementation of these identifiers will reduce our expenses in that it will reduce our training and support costs. We have high expectations that this will become a reality within the proposed time line. We fully expect all payers to be able to use these identifiers in the next few years, although our system as all vendors will tell you will still be able to accommodate the non-compliant payers. We wholeheartedly support this initiative and are very anxiously awaiting the day when it becomes a reality.
Transactions, this is a different story. It is our understanding that HIPAA is supposed to standardize not only the transactions to be used, but also the interpretation or the implementation of those transactions. However, we feel that even with the transaction standards the HIPAA implements, payers will still demand their little idiosyncracies. Even HCFA with its standards has been unable to prevent the individual Medicare contractors from altering the HCFA standards to meet their own purposes. This is a critical area. If HIPAA fails in the goal of standardizing the transaction and the interpretation of that standard among all payers, providers and clearinghouses, the future of EDI in the medical industry will be limited.
Moving down to question three, we have no concerns about the process being undertaken by the Department of Health and Human Services to carry out this. Quite frankly, I am ecstatic. I just can't wait for it.
The fourth question, we hope to have no major problems with the current transactions specified under the HIPAA. As a vendor of practice management systems, we don't care so much about the data within the transaction so much as we care about the standard transaction, the payers' interpretation of that standard, and our ability to rely on that standard to exchange medical data with payers.
Now, two issues that I want to really talk a little slower on so that the effect is felt.
MR. MOORE: Some of us need to listen more carefully I guess.
MR. FIELDING: We realized quite some time ago that the ANSI 837 would eventually probably become the standard transaction for the interchange of electronic medical claims. Consequently, we decided to use the 837 wherever the payer would accept it. We assumed that because HCFA was requiring its use by all Medicare contractors that we should certainly be able to use it to send claims to Medicare contractors without too much difficulty.
So I'm going to tell you a story. The events of the story are true --
[Laughter.]
-- but for my oral presentation, I'm going to change the names to protect the guilty.
We began with Insurance Company W because of the many Medicare contracts they held. We found that in our testing of our 837 with them, we were spending most of their time helping them debut their translator and helping them learn how the 837 worked. After several weeks and even months of this, we finally abandoned this effort with them and reverted back to the national standard format. We tried to tell ourselves that this was just one payer and that we would have better luck with the next payer. We were wrong.
We next worked with Insurance Company X to use the 837 in North Carolina. We experienced the same time consuming frustrations with them as we had with the previous one. Even though their people were very good to work with, as all of them have been, they simply had no knowledge or understanding of the 837. Their translator was plagued with bugs. We spent a lot of time with them and their translator's vendor correcting problems with it. Needless to say, we ended up reverting back to the National Standard Format with them as well, after tying up millions of dollars in insurance claims with a certain provider.
We then worked with Insurance Company Y with the same results. After several weeks of a similar ordeal, we were finally able to get to production status with Insurance Company Z in California. However, they recently took it upon themselves to go against the HCFA standard implementation guide for the 837 and made changes to suite their own needs. This caused a lot of heartache.
We finally changed our policy and decided to not attempt any more 837s until the HIPAA standards are enforced. I want to emphasize that I am not insinuating that the 837 is something that we are not pushing. In fact, MegaWest Systems wholeheartedly supports the 837 as probably, in our opinion, the preferable format to go with. Even when one looks at the National Standard Format, the same problems occur. I have identified 15 different places to send a group provider number in the NSF format, among different payers.
To summarize, we have realized by sad experience it is going to be a tough road to get payers to understand and effectively implement the 837, X12 or other MC standards. to receive medical claims data.
In the previous panel, some very interesting questions were answered. A question was asked to Kepa, why don't you send it to us in the 837, and you know my answer there. Kepa's question to the committee was how do we convince providers to send 837s instead of NSF or proprietary. My answer to that is, as a vendor, you don't need to convince me. MegaWest Systems has been trying to do the ANSI format for a couple of years now. We really like it, really want to use it. It is not the vendor that is having the difficulty with implementing 837 in the industry.
And finally, not finally, second to finally, a very good issue was brought up about standards police. There are many times in the past that I would have loved to have been able to go to some organization to bring up concerns about players that are not meeting standards and not going by the standards. I have not ever had anyone to go to. I feel that that would be a very good consideration to have an avenue for vendors to voice grievances in this area.
And finally now, and this is not on my written statement, I am sorry, one issue that I don't feel that has been addressed at all in HIPAA, unless I'm wrong, a lot of effort has been spent in standardizing the transactions, the data elements and all that in the actual message that's being transmitted, but I have not heard anything, and maybe it's just me, on the actual telecommunications aspect of sending messages from player to player, from provider to payer. That is a very significant part of our problems is the communications part of it.
Different file transfer protocols, different front end systems to receive the files, different -- some payers have reports available, some don't, some when you receive a report it removes it so you won't get it again, others it says there, they just have the last five reports there and you have to -- it's very difficult to script them. Basically, they require manual intervention in the interaction with the host. It's not scriptable by the practice management system, it's not truly EDI, it's not truly automated. It requires a human being to sit at a terminal and make a decision based on what's on the screen.
I appreciate the opportunity to make these comments.
MR. WATKINS: Good afternoon. Mr. Chairman, members of the committee, we do appreciate the fact that you've asked us here. We were talking before we sat down here as vendors that we are normally not used to being asked, we just kind of do whatever we're told to do, so it's nice to be asked.
My name is Larry Watkins. I'm the EDI Coordinator for Medic Computer Systems. Medic Computer Systems develops, markets and supports physician practice management systems and related services to physician practices, hospitals, management services organizations and managed care organizations. Medic's practice management systems are designed to manage the financial, administrative, practice management and clinical requirements of various sizes from single physician practices to large health care providers. Medic also develops, markets and supports clinical information management system products designed principally to automate the recording, maintenance and management of patient medical records. Medic Computer Systems has over 9,000 installations in 49 states that serve approximately 40,000 physicians.
Medic supports electronic transactions for its clients as an integral part of the design of its systems. To date, this includes electronic insurance claims and encounters, electronic insurance payment posting, electronic insurance eligibility, hospital interfaces and downloads, lab interfaces and other miscellaneous functions. The company also runs a full-service claims clearinghouse and the DEI network for its clients. Among other things, this network enables clients to communicate electronically with hundreds of insurance payers across the nation, mostly electronic claims transactions.
Medic adds value to these transactions through a single access point, through data error checking, transaction routing and tracking, reporting capabilities and perhaps most importantly integration back into the client's practice management system.
Medic's expectations for the administrative simplification standards requirements and the Health Insurance Portability and Accountability Act of 1996 are very optimistic. Without these standards, implementing highly effective, low cost EDI solutions has been and continues to be extremely difficult, as you've heard today. Because insurance companies and others have not agreed upon standards for the transactions named in the HIPAA legislation, our industry has been forced into much duplication of effort, delayed implementation of changes and limited EDI functionality. Medic supports over 250 electronic claims formats alone. We also support about 30 to 45, I'm not exactly sure what the number is, forgive me, National Standard Formats, no two of which can be sent to the same player.
MR. MOORE(?): I didn't think we had that many.
MR. WATKINS: Our concern about the administrative simplification requirements of the HIPAA legislation is that it does not address standards for the deployment of the transactions. Critical elements such as communication protocol, testing processes, network accreditation, trading partner agreements, et cetera are not addressed. It will be difficult to implement the new standards quickly without standards that go beyond the actual format and data content of the transactions.
Our concern regarding the process being undertaken by the Department of Health and Human Services to carry out HIPAA is that the standards be implemented in a standardized fashion through single consensus based implementation guides. This consensus process is why we strongly support the single implementation of the ASC X12 837 insurance claim format for example rather than the National Standard Format where there is no single implementation.
Medic has been an active member of the ASC X12 Committee for about five, it should say, years, rather than three. Larry Watkins, our EDI Coordinator co-chairs the ASC X12N Task Group to Work Group 19 Implementation Coordination Work Group, which has been assigned the task within X12 of coordinating the review, the comment and the endorsement process for the ASC X12N Task Group Two Health Care Implementation Guides for the 3070 Version of the X12 standard.
Medic believes in the consensus process which X12 has brought to the development of EDI standards and that this is the key to standard implementations of the nine transactions named in HIPAA. Without this participatory consensus process, implementation of the standards across the industry will not be possible. We believe that payers and other entities within the consensus process will simply say oh, well that doesn't meet my business needs and just move along. We know of no other such consensus based development process for these transactions within the health care community.
Medic Computer System believes that the goal of administrative simplification can best be achieved for clinical providers through a consensus based national implementation of EDI standards as outlined in HIPAA, along with increased functionality to support the named transactions in fully integrated computer systems and EDI networks. I want to emphasize that without that full integration, true administrative simplification will not be realized at the provider's office. Nationally adopted consensus based standards are the first key step toward accomplishing this objective.
DR. LUMPKIN: Thank you. Before we go to questions from the committee, Kepa, I have to tell you that one of the lessons that was taught to me early on when I went to legislative hearings was always to leave after your testimony, because you're always available for further questions. We heard a lot of comments in this panel and the last panel about difficulties with payers in implementing 837. What I haven't heard, and perhaps you can help me, in the interrelationship between the clearinghouses and the various vendors that have implemented 837, have you seen from the clearinghouse side or from the vendor side the smaller number of clearinghouses implementation problems with 837? Can anyone speak to that? Do you understand the question?
MR. FIELDING: I understand the question. I have to admit we have not attempted yet with the clearinghouse. We were going to start with Medicare, because that was the only real standard that was out there that we felt that we could go forward and actually have some good success with.
MR. WATKINS: We haven't had a problem because we have our own clearinghouse. It's going just fine.
[Laughter.]
DR. ZUBELDIA: One comment that we get from many of the vendors is if they can't do it with Medicare, how are they going to do it with the commercial claim. So they don't even try.
DR. LUMPKIN: They don't even try.
DR. ZUBELDIA: They're so frustrated with the Medicare process that they just give up on it.
MR. WATKINS: The other issue I would like to mention is that there is no single implementation guide and we know that the HCFA 837 guide that is the standard for HCFA that we've said is not being followed, but regardless, that single standard is for HCFA claims and really is not usable for commercial and Blue Cross Blue Shield claims. So we're nervous about implementing 837 for other entities because we don't know, because there is no single implementation guide.
There was thought that the WEDI implementation guide might meet that need, but I think now at least Medic would like to see the 837, the implementation guides that are being developed within X12 become the national single implementation guide for all players.
MR. MOORE: What's the status of those, Larry?
MR. WATKINS: I can answer that. Again, we focused a lot on claims today and there's been a lot of valid points made that there's a whole lot more transactions to be standardized than the claim. The 835 claim payment implementation guide, the implementation guide itself for the 3070 version has been approved for publication by X12. Many other guides, all of which are included in the legislation, are currently out for public review and will be through the end of, some of them through March 10 and the rest through March 30. That does include the 837 professional and institutional implementation guides.
DR. LUMPKIN: My concern in listening to this and recognizing that I may not be quite this technical, but I'm hearing that do we know of implementations of 837 where two separate entities independently develop their 837 process and actually can talk to each other? I mean is that --
MR. WATKINS: Yes, we've implemented the 837 with a number of Medicare carriers, not without pain, but we are running today. So yes, it has happened. I thought there was more implementation on the hospital side, is that?
DR. LUMPKIN: Any of the vendors here have --
MR. BEATTY: Gary Beatty(?) with the Mayo Clinic. We did develop the 837 and we got it into production. We then moved on to the next three payers that were listed in our prioritization. We sent the same 837 that we sent to the first payer and all three of the following ones were able to accept it verbatim.
MR. LUMPKIN: Great, thank you.
[Laughter.]
MR. MOORE: We have four million more to go.
DR. ZUBELDIA: From NEIC's perspective, we do have about five percent of our claims coming to us in 837. So there have been people out there that have gone through the process. On our Medicare implementation side, we have about 50 people taking care of either the paperwork to get the providers enrolled with Medicare, or doing the testing with Medicare carriers. There has been only two or three Medicare carriers that we actually had to go back to the NSF, because we could not get the 837s through. Most of the other ones, like Larry said with some pain and in about three months, you can get it through to production. There have been just a handful that were impossible and we had to go back to NSF.
MR. CARLSON: I would just like to make a comment in terms of an analogy for EDI. As I said, our company is a material management company and in the early eighties we pushed for using the X12 850 transaction set which is a purchase order transaction set. It's very similar in concept to an 837. The model though was that as a vendor, to get the order from the hospital for the supplies, it was the vendor who benefited by getting it electronic. So there was strong impetus from the vendor side to start accepting those orders.
I was also one of the authors of the American Hospital Supply ASAP(?) system in the late seventies. That jumped marketshare for American by a factor of 10 to 20 percent in terms of supply business and everyone else looked at that model and said we want to do the same. The vendors in turn who were trying to implement those, we would go direct to those vendors with our systems, or we could work through a VAN, a value-added network, which in a sense is a clearinghouse. The vendors would turn to the clearinghouses or value-added networks and say if you don't take this, you won't have our business.
So the model for pull was a little bit different, but the transaction set, the same lessons to be learned have already gone through that side of the health care business. To date, it takes about three months to bring up a new vendor when you're dealing with an 850 transaction set. It sounds very similar to the 837 in terms of what's going on. There were no implementation guides back then. I think there was just strong dollar, strong incentive from the vendor side to get that order in, because they were literally shut out of business if they didn't.
MR. MEYER: From our perspective, it's difficult as a vendor to actually ascertain how many of our users are doing the 837 because of cooperative agreements with VANs, access to clearinghouses, other translation software that they're employing external to our particular system. In many instances, where we have, for lack of a better term, taken away a customer from another vendor, contractually we were obligated to continue the interfaces that they had in place. So again, we formulated the data in that same format and gave it to whatever service was then providing that payer interaction. So directly, we couldn't comment and say yes HBOC has done the 837, however I would be very certain that a number of our customers are employing 837 either through NEIC, other clearinghouses or through our VAN relationships.
DR. ZUBELDIA: I would like to add another comment. I don't want to imply that you can do the NSF or the UB92 in a week. No, it takes two to three months to do it. The advantage is that the person at the other end of the telephone knows what he's talking about, that's a big difference. When you're trying to implement something and you know that the person at the other end doesn't know what he's talking about, it's very frustrating. So you go to the NSF so they know what they're talking about.
DR. LUMPKIN: Questions?
DR. IEZZONI: On a different topic, code sets. Mr. Knaus spoke somewhat forcefully about the challenges that you're confronted with trying to design software that has embedded within it CPT. One of the things that we are mandated to do is to look at different coding sets for medical and procedural codes. Do any of the other panelists have any comments about similar or different experiences with CPT? Is CPT the only code set that you've had difficulty with? There are some other code sets such as DSM that are produced by the American Psychiatric Association that have a copyright attached to them. Is this an issue for any other code sets?
MS. HAMBY: With respect to HBOC, it really isn't a difficult issue, it's becoming a very, very expensive issue. That is that the AMA has recently changed their fee structure. I don't have the latest, but prior to the latest one that I think came out a couple of weeks ago, it was going to be 7.5 percent of revenues plus $10 per users or per seat(?) to use if you distributed CPT codes. So that's going to tremendously impact the marketplace.
MR. KNAUS: If I can amplify the comment I made earlier, we has a vendor can pass those costs on to the end user, so it doesn't affect us directly in terms of revenue. But what does affect us is all the paperwork that we have to do to make sure every contract is in compliance and all the terms are met, and some which are difficult to do in a normal business relationship.
DR. IEZZONI: Do you have to do this annually, given that the codes are evaluated annually? Yes.
MS. HAMBY: We have to make sure that we're making changes and keeping up with it on an annual basis. In addition, there are changes we have to do to the software to make sure that we have the copyright information both in terms of the screens as well as in terms of the documentation that's being sent out to the customers.
MR. CARLSON: I would just like to add that the codes and vocabulary are a very important aspect that once you get beyond just what data elements are you going to put into it, what's the meaning behind them. I don't necessarily fault the organizations that maintain those codes for setting up fees and structures because it's a huge administrative maintenance business to keep those codes current, accurate, the meaning and the interpretation, as well as adjust to new codes that are coming out. Typically as vendors, we are asked to supply those either through look-up tables within our software so we even have to maintain copes within each site that is using the software.
DR. LUMPKIN: The question was are there other code sets which are as difficult or creating as many problems as CPT.
MS. HAMBY: No, because the others for us, at least the ones that we're using, are public domain from a financial aspect.
MR. MOORE: Staying on the issue of coding, one of the code sets that HCFA uses, I don't know many of you use it, is the HIDPIX(?) level two, which is the I would call durable goods code. We aggregate a lot of information in those code sets. One of the things that we're being pressed by a number of other people who use those same code sets is to break it to a more definitive -- one of the answers, definitive code set is universal product number that all the manufacturers use in order to deliver supplies to suppliers and so forth. Is there any opinion among the panel about that particular -- that's maintained in X12?
MR. CARLSON: Yes.
MR. MOORE: I know there are problems with all of these, and I would like to hear, because we're being pressed by both GAO, the Department of Defense and all who are looking at that as a possible alternative to HIDPIX level two.
MR. CARLSON: I can't necessarily address the HIDPIX directly, but having a universal product identifier is absolutely key to linking data together and aggregating it together. So whether it's a patient or it is a product identifier or a process identifier, which are some of the CPTs and ICD-9s and SNOWMED(?), any one of those it's important to have one source and it's important that it be a living source, because the changes within health care are so dramatic from year to year to year, that those have to be maintained, updated and disseminated in a very cost effective manner. Anything that could be done to reduce the cost of that process again can be passed on or at least not incurred by the health care system.
DR. LUMPKIN: Other comments?
DR. COHN: I shall stay away from the 837 questions, but I may come back since it is such an interesting area. One of the questions that we asked at our last session had to do with the issues of I guess future uses of data, especially around disease management. We have in our panel here software vendors who are knowledgeable about NCPDP standards, around X12 standards and NSF and so forth. Now, one of the questions that we had asked had to do with the future of disease management where we're likely to be needing data from pharmacies on pharmaceutical data of various sorts, other information from medical records, other sorts of financial and other transaction data, all to come together to allow us to identify and work around the areas of disease management.
Since all of you are responsible for software, are there issues about working between these multiple different standards, from an NCPDP standard, pulling in things from X12, pulling things in from HL7 and so forth to really synthesize that data? Are there any problems in terms of the translation, conversion? Any additional costs to end users associated with that?
MR. BECKLEY: I think the key issue there is code sets again. How you format a string of data is very minor. It is when you get that data, what does it mean. So whether it's HL7, X12, NCPDP, XYZ, as long as the code sets are the same, if I know that this field indicates diagnosis or this field indicates a particular product or service, and the code is the same for everyone, then I know what happened. I know what occurred.
We do use different code sets within pharmacy. I'm not a pharmacist so I don't know all the values, but we use ICD-9s, mostly we go off the NDC, which is the National Drug Code. That pretty much tells you everything about this particular drug that's being dispensed. Where we're starting to run into some problems is now that we're in pharmacy, we're in an area that we call professional services. I counsel a patient and don't dispense because I found a conflict, duplicate therapy or something. How do I tell the payer that I've done this? We have started to develop some codes.
Those are the areas that need to be standardized and that gets back into the clinical area. But pharmacy is being paid for that already and we need to make sure that we don't come up with unique new codes for I didn't dispense, I counseled, I sat down and showed them how to use a particular device, those type of things. Pharmacy has become very involved in that. So how you string the data together, as long as it means the same thing, we're okay.
MR. CARLSON: I think one of the things I would like to do to speak to that, the software industry basically we're talking about information modeling, information technology is what we're really talking about here. How you label the data, whether it's financial, clinical, administrative, it's all data, it's all information and how you manage it is really the issue.
Standards in the seventies and eighties, no matter how you want to look at it, were typically forms based. Whatever paper form you had to pass from one place to another, okay, that's your data, that's what I'm going to put, that's what I want to turn electronic and feed that across. Software to a certain extent was built almost the same way. What's my current problem, what's my need right now, let's develop the software for it. Then as the problem changes, I will keep adding onto it, build a little garage here, build a den off the back, put some dormers in and pretty soon your little house that you started off with that was your application has become this huge -- you wouldn't recognize it if you saw it. Other industries have found this, and they come up with plans first. They come up with architectural plans to design houses or design buildings. Likewise, information systems has evolved to that point today. Some of the technology that you see coming on board, you talk about object oriented technology, it's not a buzz word. It is a blueprint for how you look at information and how you model a business problem so that it can change and is extensible.
How do you translate that over to a standard? In effect, you need to look at the information that you're trying to model for health care and it does span the clinical, financial, administrative aspect of health care. Once you have a model or a good idea of what you're basing it on, what is a patient, what is a provider, what is a health care organization, what is a payer, those kind of objects, what are the business scenarios that interact with those objects, and you build up that kind of a model.
Then on top of that, then you start looking at specific data elements within there and you start to look for common things, like a patient name. Just between NCPDP, HL7 and X12, there are different ways that a name is represented. In the translation from one system to another, it becomes somewhat problematic. Very long names or names with titles get truncated. That's why I'm very much in favor of having an identifier of some sort because it does uniquely identify that patient or that entity whenever you're talking to him.
Well, once you build up from there, you tackle your codes and vocabulary, now you're at the very stage where you can now start putting some context meeting with all the data elements together. So how do I -- putting data together from one segment to another is no longer focused on a form per se, it's the fact that we've got a new business problem that has to move information from this place to this place and it's all based on the information model that I've got. I can then quickly adapt and develop new combinations of existing standards for the codes, vocabulary and data elements and move on. That's where all the focus leads.
Layered on top of that is the confidentiality and privacy that says who has the right to see that data and if I give it out, who have I given it to and what are they expected to do with it. But it's building up like that that most of the standards development organizations have already started work efforts on for their next generation of standards. And it's during that coordination process that we're already seeing some of the benefits come into play.
MR. KNAUS: If I may, Dr. Cohn's question, there are components that I see of the transaction sets that will help improve the quality of information and usefulness in its clinical area. But when it comes to diagnosis, supply, procedure codes, that process will not make those any better. The coding that's done on the original front end in translation of medical records is key to making sure that that part is accurate and useful to people using that data for clinical studies.
DR. LUMPKIN: I'm intrigued by the comment in response to that, because we heard earlier that somewhere in the neighborhood of roughly, somewhere between half to a third of the information that's needed by those who are looking at monitoring the health care systems, the NCQAs, the Joint Commissions, are captured in the billing data. And I heard testimony today that some of the systems involved are involved in moving information between various providers, including hospitals and clinicians and laboratories.
How do you do that? We're talking about all the difficulties we have with the billing data, but you're all building systems now that at least some place you've got a doc sitting in their office and they want to know what the lab results are for their patients. It's run by a hospital lab, it may go to the hospital and then from there out to an external lab because it's a low volume test. How does that information flow, because if you're setting a model based upon the business, that's the business. All this billing stuff is kind of an appendage upon that. How do you make those standards?
MR. CARLSON: Well, in effect that's what HL7 or Health Level 7 was started in 1987 to address that. At that time, the movement in the industry for systems was one of office centralized or departmental systems, individual or islands of information, if you will, to connected systems. Local area networks provided that vehicle within hospitals themselves. But now the health care organization is much larger than that.
Well, HL7 started out focusing on those clinical needs within the hospital from system to system over a local area network. Now fortunately, we do have things like the Internet and health care has expanded from, a hospital may own the clinic or it may be a partnership with the clinic or the lab system in -- they use an HL7 format, which in a sense it's similar to X12 in terms of the fact that it has transactions, if you will, it handles things such as doctor's orders, physician's orders, results, things of that nature. As opposed to calling it 837, it calls it an order entry transaction.
MR. MEYER: I think too to further that, to a certain extent we have to consider the advent of the computerized patient record and where we're moving with that, and the function of literally the virtual longitudinal patient record which is represented by clinical repositories. Within HBOC and our enterprise model, the repository plays a critical role, just as you've spoken, both in the form of enabling that longitudinal record and providing that historical preview.
We're also talking about the concept of, somewhat radically, the concept of an episode as it relates to a disease management function. Is this current encounter for billing purposes actually a result of the fact that the patient has diabetes? The episode is really diabetes as it impacts the patient's life cycle and then relating it to that episode from the disease management role, not just the fact that the patient is in for a related condition and he gets billed for that and that's the end of it. That's certainly not it. But it all revolves around the concept of a repository, clinical data being intermixed with financial data, and then subsequently also supporting that decision support function which comes into play, either in the development of care plans, through disease, through risk management, or through the basics of cost accounting and demographic studies.
MR. BECKLEY: I mentioned that we were passing clinical information already and you ask how are you doing that. Pharmacy has not had a problem with billing for probably five years. That was resolved a long time ago. It's immediate, it's not at the end of the day or sometime during the day roll up a number of claims and send them in, each one goes like credit cards today. It's exactly the way it is. We've also overcome most of the protocols, we still have some, but we've overcome most of those.
So we've spent most of our time now focusing on the clinical piece. That's why in 1994 that's when we started working on our first pass at that and we put that into place. So we're past that bottleneck for a very high percentage. And as I said probably 70 percent of all prescriptions filled, of that most of them are done on-line immediate. The days of tape billing and paper are very, very minor and a small piece. So we focused on attaching the elements to the claim because we all understand the claim, and so we're now putting in new pieces to send to drug utilization reviews, diagnosis, other pieces of information that are helpful to the payer and other folks that are taking a look at the data for drug therapy programs.
MR. WATKINS: I can say as a practice management system, that we have wasted way too much time on the types of inefficiencies we've been talking about. That's one of the reasons why we're excited about the legislation because we have to spend so much of our resource trying to keep up with nonstandard implementations of the same thing. That's why I talked about duplication of effort and limited EDI functionality, because we're having to spend so much more of our time on those issues. We do lab interfaces, we do hospital interfaces mostly with HL7 transactions, but we're not able to put as much resources as we would like to because of all these other issues.
DR. LUMPKIN: So as I understand what I'm hearing is that many of the problems that exist, which is what administrative simplification is to do, is because of the fact that multiple payers require different things and have not implemented or come into compliance with 837. But are all of you, would you all feel comfortable if HL7 were the standard for those kinds of clinical information that are currently covered by that? Are you already doing that if it's that good?
MR. CARLSON: Yes. One thing I would like to add, and I hear this voice of HL7 so to speak, there's one particular area, for example diagnostics and imaging that HL7 doesn't cover, but ACR and NEMA, the American College of Radiology and the National Electronic Manufacturers Association already do. In fact, it's trying to eliminate duplication of effort and looking at them saying you cover that, you have domain expertise and we don't, you take that aspect of it and let's work together on the patient administrative part of imaging and they use HL7 from that standpoint. So there's an example of where HL7 from a clinical standpoint didn't want to tackle something as large as the imaging and we went out and formed a partnership with ACR NEMA.
DR. LUMPKIN: Thank you. I get the picture.
[Laughter.]
MR. MEYER: More to the point of the 837 and its attachments, I think you would find, and again this discussion came up during the X12 meeting last week. In many times, the attachment takes the form of a physical paper document sent to the payer. One, because standards have not been readily implemented for image and document processing. Of course, the problem that that creates from a clinician's viewpoint is that now we have clinical information that's taken out of context. And for that perspective, a clinician can do nothing with it. So this meaningfulness question that came up here is very valid when you talk about attachments, because in most instances, the attachment is simply an effort for the provider to assure the payer that a certain function relevant to a procedure or process was in fact completed.
The outcome, the relevance of that clinical data has no bearing to the payer. He doesn't care. The fact that he had the CT scan is all he cares about. That's where the difficulty of attaching clinical data to billing data comes into play because the perspective is different on what you want to attempt to do with that.
MR. SCANLON: A different topic. Are there -- the law also calls for security standards and security policies as well as the unique identifiers and the classifications as well, are you aware in your experience of any existing protocols, policies and so on that could be entertained as candidates for standards in the security area, again for electronic data interchange, where the information is identifiable? Are you aware of security practices or policies that are so effective and in such wide use that they could be considered as standards? No?
MR. CARLSON: We know of starts in places, but we don't know of anything that's up and implemented that --
MR. BLAIR: I just want to respond. There's going to be a section in the inventory standards document that Rick Peter has compiled where he pulled together guidelines for data security from the Computer Based Patient Record Institute, ASTM standards for data security, initial work efforts within HL7 on data security, who work within a number of different organizations to begin to cooperate on data security issues. You will get this tomorrow and get to see the book. There's a lot of work that still needs to be done, but I think that you will see that there are work efforts that we could bridge off of.
MR. MEYER: I think I would hesitate to recommend mandating a specific scenario there because the area of cryptography expands every day. What you say today is it is going to be broken tomorrow. So you really need to focus more, I think as Jeff pointed out, on the guidelines and to a certain extent the penalties involved in that, because as quick as we talk, somebody has got a new cryptographic program.
MR. CARLSON: I would just say it's recognizing it's in two parts. The fact that nobody could read it, that's been solved already in other industries. The fact of who should get it and what parts of it should they see and who has to keep track of who you gave it to, those are issues still up in the air.
DR. COHN: Actually, I want to change the subject just slightly except to comment David, when you started commenting about unable to read, I thought you were referring to my medical record.
[Laughter.]
It is with some ambivalence that I loop back around to the 837 standard. I actually want to just ask you all a question about that. I've heard a very wide range of opinions and thoughts from the panel here, as well as really from everyone else we've talked to during our various panel sessions. I think what I'm beginning to understand is that the 837 standard Lisa has felt to be currently immature, and that's really what I think I'm hearing from a lot of people.
Now, I guess the question I would have for all of you to respond to is that the standards that we're going to be promulgating would go into effect a number of years from now, I'm trying to think, 1999? That's the implementation date.
MR. MOORE(?): That's the deadline. It can be implemented prior to that time, but that's the outside time.
DR. COHN: Yes, recognizing that we actually have some time to do things that for example might make that standard something that's possible at least for certain uses. Now, having said that, what would it take from your view to allow you to have assurance that that would be an appropriate standard that might supersede the NSF or the UB92 variations and what would it take between now and then for us to move from potentially a multiple standard environment to a single standard in that time frame?
MR. WATKINS: I think we've got some experience to answer that question. We've talked a lot about HCFA and Medicare. The problem with implementing 837 for Medicare has gone way down as we've gone through this time. Most of our nightmare stories are during the year when HCFA mandated either the NSF or the 837. We had to make a change from a proprietary format. Many of us said, let's go with the 837, we know that's where the future is, and that's where we ran into a lot of lack of education really on the part of Medicare contractors. We're not finding the kind of difficulty there now that we had then. We do still have some.
I want to make sure it's clear, we haven't experience as a vendor, and I haven't heard anything here, that there's a technical problem with the 837 or that it doesn't meet the need. I think what we're expressing is the lack of education on the part of the people that you're trying to work with to get it going. So it's immature in terms of how many people are using it and in terms of how much experience they have with it.
In fact, as someone who is experienced with the 837, I can give some examples. We found it actually was easier to bring up than the NSF, because the NSF does have a lot of ambiguity in it that the 837 does not. So I think we're seeing some of that maturity already occurring. It occurs through experience and through the use. Unfortunately, that's I think a reality that we're going to have to realize. I don't know how this education of the industry occurs. It took us a long time as vendors to get to the education level on the NSF. I mean the reason why that's in place today is because it's been out there for what six or seven years now.
DR. LUMPKIN: Let me see if I understood you correctly that when you bring up a new payer, that it's easier to bring him up with 837 than it is with NSF?
MR. WATKINS: If they're knowledgeable about the 837, it -- with a Medicare contractor it tends to be easier because it's more standardized than the NSF tends to be, yes, sir.
DR. LUMPKIN: Okay, so as opposed to some of the stories we heard where you were currently using NSF and then now you're trying to change the 837, that's where the problem existed that have been raised here today. Is that a fair statement. Is that what we heard?
DR. COHN: I think that's probably what I remember, we have to remember that Mr. Watkins is also Chair of the Implementation Guide Group.
[Laughter.]
I would think if somebody knew how to implement this, he would likely be the one. Am I correct?
MR. BECKLEY: The 837, and I'm a little bit familiar with it, but not much, it doesn't meet the pharmacy industry's needs because it is batch oriented. You can argue batch, fast batch, interactive, but a pharmacy claim is very fast, very small. To go to an 837 would in essence, the way it's used right now, would put pharmacy back about six years. So to say would 837 work, it probably would if we wanted to do batch pharmacy claims, but we don't because then we lose all our clinical aspects of getting back immediately, there's a problem with this prescription or whatever.
So I go back to, and I made mention in my presentation the business needs, what is your business need. If I was doing batch, I would do the 837. As a footnote, for reconciliation for when the tape and the check come in, we are working to use the 835 and have endorsed the implementation guide that was mentioned earlier, pharmacy has. So we take a look at the business need, it's not interactive, pharmacy does that.
DR. LUMPKIN: I think we've heard fairly loud and clear and consistently that NCPDP shouldn't be messed with.
[Laughter.]
Am I misinterpreting what we've heard?
MR. BECKLEY: Just as far as the electronic claim goes, because pharmacy doesn't use all NCPDP standards. We go out and find the best out there. We're working with HL7 now on passing patient information back and forth. So we got out and find the best out there and that's what we want to use in pharmacy and a lot of that is X12.
MS. HAMBY: I think one of the comments too is it doesn't matter to us the specific standard that you require. What we do want to see however, and I think I can speak for all the vendors here is consistency in the standard, consistency not only in the standard, but in the implementation process so that everyone understands exactly what the content of those standards are.
MR. FIELDING: And the education.
MS. HAMBY: And the education, right.
DR. LUMPKIN: It was mentioned in an earlier panel about a reference implementation that people can test it with. I understand that there actually may be something already that's been developed, but that kind of thing would that be useful?
MS. HAMBY: That's great, that's already in the marketplace actually from HCFA, because they already do something to that level for cost reporting.
MR. MOORE: Is that good?
MS. HAMBY: It's excellent.
[Laughter.]
You go through the process before you submit your cost reports, so the same concept would be --
DR. ZUBELDIA: As long as the Medicare contractors comply with the reference, it would be great.
MR. WATKINS: I was going to shout my amen when Kepa was talking. Those are excellent, both points, the reference and then the compliance, the police.
DR. COHN: I was going to comment, it probably is not fair for me to ask the question I just did without giving you a lot of thought. I would really appreciate it if you submitted anything written or any thoughts about what it would really take for you to feel comfortable with the 837, what sort of proofs would have to be in place for you and the people that you're representing. I guess that's something that would be helpful I think to the committee.
I did create a joke and I hadn't intended to Larry, when Dr. Lumpkin, John was basically asking you about issues related to 837 versus moving over to NSF. I was wondering actually would you care to answer that one from your own view? Is the issue really the 837 standard, or is it really the transition from one format to another?
MR. WATKINS: No, I don't think we've ever transitioned from the NSF to the 837. We have transitioned from the older proprietary formats to one or the other. Mostly, we've transitioned to the 837. What I'm saying is that that's easier to do today than it was in 1995 when we were all under a lot of pressure to get it done, that's the point I was trying to make.
If I can make one other point that I think is very important to this whole discussion, that I don't think is taken into account many times. The National Standard Formats and the proprietary formats that preceded it is a processing format for many payers. I'm talking specifically claims, this doesn't really apply to many other transactions. For example, the 835 is the most widely used electronic remittance format out there, but I don't know of anybody who uses it as their internal processing payment format. On the claim, that's where we are. We went from an environment where every payer would take their internal processing format and say send that to me. We as vendors of course would say yes and we would do that.
What happened is Medicare went to a national processing format, the NSF. They all have implemented that as their processing -- I think all -- have implemented NSF as their processing format. So then we're asked to do that. The reason there are changes to the NSF, in defense of the payers and of HCFA, is that it's the processing standard. So in order to process the claim, they have to have the difference or it's not going to process. That's the difference. What we're looking for is a communication standard, something that can be translated back and forth that people don't have to worry about whether it's going to change my processing. I'm just trying to get the data. I think that's real important.
I think the 837, because of its compression and because of the intent behind its development and because of the consensus that's gone into the development process, can better handle the -- I'm not talking for pharmacy claims -- can better handle the health care claims that we as a vendor are trying to get across in a standardized fashion.
I don't know what it would do to the payer industry, and I guess I don't understand in the payer industry where, for example, where the National Standard Format is used as a processing standard, what kind of an impact that would have if you suddenly changed it on them. It seems like that would have more impact than introducing an 837 where they could translate in and out and get the data across. So anyway, that's just a -- I like to think of it in terms of processing standard versus communication standard.
MR. MOORE: HCFA is going to be moving to the Medicare transaction system at the same time that we will implement all these standards, in the year 2000. We will not be using those processing formats that are out there in Medicare intermediaries and carriers. It will be an entirely new system. If I used an 837 as the device, will the providers be able to support that? Will they opt out of the 837 and go to paper because that's a definite fear that we have?
Small physicians, you have all seemed to express, except for the pharmacy group, that there is not a problem out there with the provider community, but our payer community should be able to accept it, except for the ones that Kepa deals with.
[Laughter.]
But we've been always concerned about the provider industry being that there are, in our world when you take not only physicians but practitioners of all types, probably over 1.2 million of them and we couldn't afford to eat the paper on all of those if we said go to this particular format.
MR. KNAUS: There are about 1,500 different types of practice management systems in use in this country right now.
MR. WATKINS: Is it that few?
MR. KNAUS: Yes, that few, maybe there's more from home grown, the doctor or staff wrote it, to a small local regional player all the way up to the firms you're seeing here that work on a national basis and have many clients. Many of them are on older legacy type system where the original code programmer has died or whatever. Some of them are going to have great difficulty and will probably have to retool. They're going to have to get new technology in if they elect to meet the new standards. Some who work with firms here that have the resources to be able to make those standards available to their client base will be able to implement then.
MR. CARLSON: One thing you might do is if you identify that constituency that may be of a concern in terms of what they can do, would be to define the business scenario problem, what you expect and then put it out to bid. We want a product that costs $1,000 end price and we want it to do the following things, who wants to bid on it.
MR. BECKLEY: Not pharmacy, promise. As a measuring stick, when we changed to a newer version of a claim format, updated the NCPDP standard, it took all the different vendors out there, the payers got there pretty quick, it took them in excess of 2.5 years and some of them are still sending in the old format because the software vendors, the small ones in particular, as you mentioned the small mom and pops out there, they couldn't upgrade or the hardware couldn't support it. So it is a very long transition period, that was my point.
MR. MEYER: Just in the general nature of the beast, time and development plans wait for no man. You mentioned 1999, in our organization, and I assume in many others, we're already starting to lock down development resources for 1998 plans. Those will be finalized probably by the middle of the second quarter of 1997, much like you start the budget process now for 1999. It's the same type of scenario. So all of us have limited reaction times to these things, or hopefully we've been smart enough to set aside contingencies or blocks of hours that we just allocated to this generic area called standards and when something comes up, we react. Hopefully the resources are there.
DR. LUMPKIN: It's time for us to take a break. I would like to thank the panel for coming. A little homework assignment. One of the issues that we were discussing, and I think it would be useful for us, is to get a little bit more specific on what kind of standards do you think are mature enough to be put in place. We've talked a lot about 835, 837, we talked about HL7, but are there other standards that you think this committee is ready to pass on, particularly in relationship to that kind of information that may pass between individual providers, which your systems are currently already written to do. If you feel that there are some that are worthy of that, this committee would certainly appreciate your comments on that.
Okay, we will try to do a 10 minute break.
[Brief recess.]
DR. STARFIELD: Thanks for setting the standard for how to reconvene after break. I appreciate your promptness. I'm Barbara Starfield and I'm Chair of the Subcommittee on Health Data Needs, Standards and Security. We've been spending the day responding to the imperatives that come from the administrative simplification provisions. The subcommittee has a much larger charge. It has to recommend to the full committee, and then of course to the Secretary on health data needs, data collection efforts, data utility for national, state and local purposes and health data standards and security. So we will turn to this somewhat broader mission in our session this afternoon.
I'm pleased to welcome Ed Hunter and Ross Arnett to talk about the HHS Survey Integration Plan. Thanks for coming.
MR. ARNETT: Well, when we began survey integration, we were told that it was a fairly chancy enterprise and surely enough, now that we're part of the way through, it's been published and summarized in Chance Magazine, a copy of which you have in front of you.
[Laughter.]
Also in front of you are some talking points that I will follow. What Ed and I had planned to do today is for me to briefly take you through the survey integration plan, talk about our progress to date and the future steps that we see. Ed will take over and talk about some issues and lessons from survey integration and talk about potential roles for the national committee that we would certainly like you to entertain. We've done this innumerable times, so please feel free to interrupt or tell us to speed it up, whatever suits you. But we were looking forward to a dialogue with you at the end, particularly on these potential roles of the national committee, because I do think you have a role that can be very helpful to us.
In the survey integration, and I'm flipping through this handout now, we started off looking at about 300 surveys or mythical surveys in the Department. We broke them down into sectors, households, institutions, employers, providers, and capacity and infrastructure which is referring to the Public Health System. I'm on the second page of the handout.
Because of the importance of the cost of some of these surveys, we decided to focus on the most expensive. It also was happenstance that two of them, the National Health Interview Survey was about to undergo a major revision, and the National Medical Expenditure Survey was about to be fielded. So it was imperative that we look at those surveys first. We looked at surveys that we felt were logical to integrate.
When we looked at the surveys, we didn't find any surprises. There were multiple surveys conducted by the Department. They overlapped. Not all overlap is bad, but nevertheless we felt we needed to look at overlap. Even though there was a lot of information collected, we certainly found that there were some inadequacies in the data collected and also gaps where there were things not collected. An example of the latter was information at the state level. We also didn't feel that we had taken full advantage of integrating with private sources of information.
The next page talks about the objectives that we had for the surveys. We needed them to measure and monitor and for our analysis and the analysis of all those people out in the public that use the data. We needed to measure obviously the population, but also the health system itself which includes the providers and the payers.
Our guiding principles for the start of the survey integration, we were interested in streamlining and rationalizing the surveys. We were not interested in throwing out the good things. The surveys still do and did provide a lot of information, so we certainly didn't want to throw the baby out with the bath water. We needed to look to filling critical gaps in our data sets and improve the analytic capabilities of our data, reduce the overlap and duplication that was burdensome and unnecessary.
The place that we started, and you might argue that we started with the low hanging fruit, was to integrate the households. It didn't feel like low hanging fruit at all through the process, but they were the --
PARTICIPANT: Low hanging fruit on a very tall tree at the time.
MR. ARNETT: Right. Some of it was very ripe, maybe over ripe too, but they were the surveys that were ready to go. They were surveys that had been discussed in terms of integration over time and for a number of reasons just hadn't been brought together.
So we looked a the Health Interview Survey as the broad based population survey of the Department that seemed like a good launching point for the rest of the Department's surveys. We looked at how we could integrate the then NEMIS(?), now MEPS(?) survey, with the Health Interview Survey. What we did in the integration was to draw the NEMIS survey or MEPS survey from the Health Interview Survey.
That had a lot of advantages. First of all, it saved a lot of money, somewhere between $6 and $8 million from the processes that had been employed to select the sample for the NEMIS survey. It also increased the analytic capacity of the data because we now would be having the observations from the Health Interview Survey and then going on and having the observations from the MEPS which get the expenditure information for the household.
We looked at the Medicare Current Beneficiary Survey and how it overlaps and could be integrated with the NEMIS survey, and that's something I will talk about in future steps. We looked at things like the National Health and Nutrition Examination Survey, which is now being drawn out of the Health Interview Survey as its sampling frame. And we looked at a number of other surveys that could conceivably be drawn from the NHIS, as its household frame.
Future steps in the integration, well current steps in the integration is to look at how we collect information on employers. We've had two kinds of surveys going on in the Department, principal surveys, one was the NEMIS type survey where we did a follow-on to employers from households to collect information on employment and also the insurance offerings. Then we've had independent employer frames conducted by HCFA over a number of years and most recently by the National Center for Health Statistics where the frame is the employer and where we look at all of the offerings that we make and the cost of those offerings and the kinds of coverages that are offered.
Those two have been brought together now under the MEPS as a single survey with two sources of identifying the employer, but one set of questions, imputations and edits that we employ once we've identified that employer and when we approach them for their information. So that is another step in the survey integration, what I call phase one of survey integration which we have more or less behind us at this point.
On institutions, we have three nursing home surveys in the Department, the National Nursing Home Survey at NCHS, the National Nursing Home Expenditure Survey as part of the NEMIS survey or MEPS survey, and nursing home information collected out of the Medicare current beneficiary survey. The next phase in survey integration is going to be how we cobble those together and make hopefully better sense, or at least greater efficiencies out of those three.
DR. LUMPKIN: Is that a sample survey or is that a universe survey?
MR. ARNETT: They're all samples. In the case of the NEMIS or the MEPS and the National Nursing Home Survey of surveys of the facility level, from the MCBS, they go to the facility after being identified by Medicare beneficiaries.
A big issue facing us this year, and germane to I think a lot of issues surrounding Kennedy-Kassebaum and unique identifiers and a lot of other issues is how we can rationalize our collections of information from providers of care. A lot of issues there in terms of defining the boundaries and figuring out how we actually get an inventory of those people and from that inventory then do the more detailed data collection where we fill in.
At the state level, NCHS has a plan, and maybe Ed can speak to that a little bit more if you want to hear about it, to take advantage of the Immunization Survey and use that as a launching point to ask some NHIS type questions, Health Interview Survey type questions of people over the phone while we're collecting information from them on the immunizations. The problem with state has been that it is very expensive. To field a satisfying survey, multiplied by 51 or 50 of the costs of national level surveys.
To conclude this section, we feel that survey integration has yielded a coordination of efforts. We have filled some of the gaps, there's more to be filled. We now have a continuous collection of expenditure information from the MEPS. We've linked some of the surveys and have plans to link the others, and at an individual level we have reduced some of the respondent burden, particularly for the employers where we come to them once and ask them the same set of questions.
We've gained a lot from that in terms of efficiencies, sampling efficiencies and data collection efficiencies. Questionnaire design, we really have become quite good in the Department in sharing our questions and attempting to assure that they're consistent or where they're different, they're different for a purpose. And of course, this is all necessary given the ever dwindling resources that we're going to have available to us in the upcoming budget years.
We worried at the beginning of survey integration, and still worry about some of the risks of integration. We were under a lot of pressure to move quickly. By putting all of the surveys together, we have fully exposed to the world of budget people how much they're costing us and it makes a nice appetizing target to think about reductions. As the surveys are linked, their fates are also linked. If one of them falters or falls behind, the rest are impacted by that. We worried about trying to over consolidate and come up with one grand survey that did it all and was crushed of its own weight. And we will experience, as we limit the number of surveys, competing demands for all of the supplements that many desire to add to these surveys. There will be limited vehicles for that.
Now, progress to date, just to summarize quickly, we have integrated the Health Interview Survey and the National Medical Expenditure Panel Survey. We have also integrated the two employer surveys.
Steps for the future, I mentioned the Medicare Current Beneficiary Survey. The survey integration plan submitted to the Secretary called for merging that and the MEPS. It was decided at that time, at the time that we submitted to the Secretary we wouldn't do that, since we did not have a fielded and viable MEPS and we didn't want to interfere with the Medicare Current Beneficiary Survey.
There are issues of the uses of the surveys. The Medicare Current Beneficiary Survey is used for programmatic purposes, as well as analytic purposes and those issues have to be sorted out primarily at the Data Council. We do need to address the Nursing Home Survey Integration and I mentioned the development we need to do on the provider survey.
One last point on integration, it does expand beyond the Department. I mentioned that we have integrated our employer survey, but there are other employer surveys conducted by the federal government, the Census Bureau conducts some, certainly the Bureau of Labor Statistics conducts a survey of employers that collects a lot of the information that we collect in the insurance component of the MEPS. And we are going to have to be concerned about those overlaps and how to deal with them.
We have proposed an interdepartmental working group that will look at these issues and try to sort out how they can be dealt with. There are some significant differences in the way the samples are drawn and the purposes to which the data are put. We will need to resolve those broader issues. Mr. Ed.
MR. HUNTER: I always hated that when I was a kid. [Laughter.]
That horse eventually died, so I'm over that now.
I guess one thing, the article that Ross referred to is actually an editorial in the ASA, American Statistical Association, there's more than one of them, in their quarterly magazine. It has some of the background that Ross touched on briefly about why the Department felt this was an important thing to do, and in some ways why we think, even though we have done some specific steps, there is probably reason to think there will be more steps to be taken because the same kind of imperatives that were at work a year or two ago are still at work now, the pressure on budget resources, the kind of external impetus to be more efficient, the data gaps and the need to fill them, and then just the analytic payoff that can come from some of these things.
At the same time as we undertook this, the Department established the Data Council, which you all are more than familiar with. Some of the things that we have been working through in the integration process are also issues that involve the larger question of what the Data Council does.
I wanted to touch on just for a minute about what's happening with our process, because we really think of integration not just as a series of steps on the sampling or the questionnaire redesign front, but more of an ongoing kind of iterative process. In some respects, although this sounds more glorified than it is, it's a change in the way the Department thinks about the way it collects and obtains data.
Three or four or five years ago, when we might have thought of designing the next wave of the expenditure survey, the presumption was to have an agency do what it in its internal staff would do, and as it felt appropriate bring in other outside experts where it didn't feel that it had in-house expertise. I think the presumption in a lot of ways has shifted to a greater or lesser degree, depending on your individual agency's perspective, but the presumption is that there is more of a collective interest in what these surveys look like and what they do and more of a collective judgment on is this the right mechanism to obtain this data. Certainly when you overlay the Kassebaum-Kennedy and the standardization process and the availability of outside data sources, that all comes to play at the Data Council in determining whether a survey is the right way to get some of this for the long run.
But it really does change our thinking in terms of when it is the right time or whether it's the right thing to do to launch a new survey as an independent mechanism. Ross mentioned our sort of budding efforts to sort of look at state and local data and build on the immunization survey. We call that SLAITS, the State and Local Area Integrated Telephone Survey.
It might have been three or four years ago when looking at the need for insurance coverage, access to care and health status data at the state level we would go off and do what from the sampling and statistical point of view is the easiest thing and design an independent survey. Instead in this new environment, the first option was to look at an existing survey and existing questionnaire sources and see if there is some way that this could be done in an integrated way, including kind of pushing on to the agenda the question of what other uses of integrated mechanisms, if you look at the mechanism and the contract as being distinct from the objective for the data need, what other things might we be able to do in some joint kind of framework. So that leads you to looking at things like how do we ask questions on the Behavioral Risk Factor Survey and are there some opportunities for using shared sampling frames or coordinating things better.
So, we've actually learned some lessons along the road. We each have our set of scars and other cases of evidence --
MR. ARNETT: Dates -
MR. HUNTER: Yes, we have some dates that we have written on calendars that we're not the happiest of days. We learned what we already probably knew, that interagency collaboration is actually a very difficult thing. We opened this editorial by referring to interagency collaboration as an unnatural act. We certainly see evidence of that in the federal government across the board and it seems as though turf is a much more -- Phil Lee has always described data as being a four letter word spelled T U R F. I think there is ample evidence of that.
We have certainly found that it takes more time and effort and it actually causes the whole system to come to a crashing halt sometimes when you have multiple players with very different perspectives and very different interests coming together, even in the best of fates to try to work out a problem. I think that's potentially more difficult when we look across the government. OMB, in this latest President's budget that was released last week, is calling for a great deal more coordination among the federal statistical agencies, so issues with the Bureau of Labor Statistics and Census on employer surveys and between us and Census on demographic issues I think are going to become much more paramount and also much more difficult.
But we have also found the payoffs are, at least on most days of the week, worth the efforts. The $6 to $8 million that Ross referred to as being saved by not having to do an independent sample is a real $6 to $8 million. One way of looking at that is we may not have been able to do the expenditure survey but for the fact that we were able to do it more cheaply.
We are finding that there are some very interesting analytic possibilities. We're starting to get into how we coordinate the release of data. This plan is now mature enough that we have data from the first of the linked surveys. The expenditure survey data is starting to come on-line based on the same individuals that we will now have data from the Health Interview Survey. The question becomes what do we do to take maximum advantage of that.
A second lesson I think is that there are just an awful lot more technical and conceptual problems than we could have anticipated in the six weeks or so that the Department pushed to get us together on this. We did this under a lot of very high level of attention within the Department and that was great because it pushed people to come to some agreements we might not have come to otherwise, but it also forced us to do things, assuming that a lot of things would happen down the road.
We're finding that just on the sampling issues alone, there's a lot of things that you can't anticipate right off. The Health and Nutrition Examination Survey is one of those surveys that will draw a sample from the Health Interview Survey, but it's a very specialized survey where there's exam centers that move around the country and you can't move them to all the places that the HIS sampled because the HIS just needs to send a person in a car. So there's a lot of things that we need to work out in terms of sample design. I think we're finding there's an awful lot more that we need to be thinking of and more research that needs to be done so that in three or five years when these surveys are designed with this in mind, we will have a much better head start and be able to make much better use of these linkages.
The last thing I wanted to mention before talking more about the national committee role is where we are in the Department on the process side of this. This integration process started with a very time limited thing with kind of an ad hoc group which evolved into the Data Council. The Data Council is still trying to find its way on how exactly does the Department as a whole plan and sponsor surveys that are done, obviously they're done within agencies.
I think we have a good consensus on the need for more collaboration up front, a process where all the agencies and people on the outside as well are alerted to what data collection plans are down the road so that there can be a maximum amount of input and collaboration. We're still struggling with this balance between the prerogative of the agency and the imperative of the agency to actually get the job done versus the desire of the Department and all of its analysts in various far flung places to make sure that the information coming out of those surveys is what everyone needs rather than a somewhat more limited focus that might have come about without that kind of input.
So I think that's where we are. That's a very live issue this week, the Data Council is going to discuss it again this week. We've been at that for some number of months and will come back and tell you how that comes out, I don't know how to phrase it.
We thought a little bit about what the committee itself might do. I think there are a number of areas in your broader mission of the subcommittee and the committee as a whole. We're very anxious for the committee to help keep the surveys in the context of these other data sources and over time certainly balance when there are things that can be obtained through other ways that we now obtain through direct data collection. I think that's certainly a, the committee is an excellent place to balance some of that.
We think, in the short run, certainly as the Department moves more towards developing a, I hesitate to use strategic plan, but more of an advanced plan or kind of a cross the Department view of how surveys are going to be done and how their planned and using that to look for data gaps and opportunities for either the types of linkages that we talked about or more on the redesign and kind of tweaking of these surveys to meet different, fill different gaps.
I think that's a place where we really would like the committee to help us in either evaluating what we come forward with, or in pointing out places that we need to go and look and work. We probably can have a dialogue over the course of your work and what's the best way to stimulate that kind of thing, whether it's for us to bring things from the Department to you, or whether there are things that you would like to do to stimulate our thinking within the Department.
A second area is to help the Department in setting priorities across different areas that -- I don't mean this in the sense of trying to set a department budget, I mean this is something we're having a hard enough time figuring out how to do it within the Department. I don't think it's reasonable to ask the outside world to help us with that as this point, but I think there are some data priorities that we think, give the range of data gaps, that would become obvious through some kind of a more consistent and concerted effort to look at how our data systems fit together. I think helping us sort through which ones are the first order of magnitude and which ones are beyond that will be very useful.
Then finally, I think helping kind of keep the pressure on to do these types of cross agency collaborative planning things. One thing that I think made this possible, as I mentioned, was there was an awful lot of pressure from the Vice President, from the Department Secretary, the reinventing government process really led the way for this by raising the level of visibility and the priority. That process itself is over with. It's when you go back after that six weeks and you return to your daily job and you try to figure out how you're going to get the next thing done, that it's very easy for all of us to go back to doing what is probably easier than working with that agency across town or downtown.
So I think to the extent that these things do have payoffs, I think it would be very useful for the committee to keep reminding the Department that there are things we haven't quite finished yet.
Then I think there will be some specific things that we will bring to the committee that we have started to pursue. Ross mentioned the health care provider area as one that's next or intermediate next on our radar screen. Not only do we not know how we're going to integrate the specific surveys that would go -- a brief example the NCHS provider surveys go and sample hospitals as an example, and then within hospitals will get discharge records. The same thing applies, the same end product results when the expenditure survey goes to a household, identifies the fact that a person has been a hospital, and then the survey goes and follows up to get that record. That happens, as physicians we have a mutuality of field operations when it comes to nursing homes and others.
How we bring those things together so that the distinct data interests of those two different types of approaches is maintained, while maybe you can do something about more efficiently knocking on the door of the hospital remains to be seen.
But backing up even one step before that, we're not really that clear, at least I'm not, of what it is we want to know about these providers any more and what it is we want from either the sort of inventorying approach, and John, you asked if your samples are inventories. They are all samples, but maybe there are some things we need to know that is on a broader basis about a more complete look at what's happening in the system, not so much the encounter from the discharge record, but what's going on with hospitals more generally. These are not things that we go out and collect data on, but they are things that we have an analytic interest in as a Department and an interest in providing data to the public to use.
So, we're actually launching a project, the Department Data Council, ASPE and NCHS, to just drop all the way back to asking those very basic questions, why are we in this business, what is it we want to know, what are the questions we should be asking, what are our policy concerns that require provider data or information about capacity and supply. Is it the connection between the providers, is it the risk relationships, is it the affiliation, is it the distribution of resources, is it the encounter data that we get from them, or combinations of all of those things?
We're going to be looking closely at that over the next year and holding some workshops. I think that's a practical example of where the committee can have a role as well.
I'm kind of running through a number of different things, and maybe I should stop there and we can have questions or discussion.
MS. COLTIN: It sounds as if in the near term your focus on survey integration is integrating among surveys, but I wondered about the extent to which you've considered the integration of survey data and transaction data and how your approaches to the survey sampling and whatever, as well as issues around standardization of data elements that would be necessary for linkage purposes -- I'm thinking of not only the national patient identifier but the NPI, the payer ID, some of the other fields that might be necessary. Are you thinking ahead in your survey design to standardizing some of the data elements in surveys that might enable you to link back to the transaction data, both to validate some of the survey responses and vice versa, but also to supplement them?
MR. ARNETT: We're thinking about it, although we're thinking that it's maybe a little bit further down the road. I've been watching the work that Mike Fitzmorris in his shop at our agency has been doing in terms of the electronic patient record and wondering how much of that would obviate the need for us to do the expenditure survey. Frankly, I think that would be a wonderful thing, but I don't have the sense that it's a near term thing.
I think that there are a lot of opportunities with the work being done at HCFA, particularly on the provider survey where we need to collaborate a lot more. All of us are on the Kassebaum-Kennedy Implementation Teams and watching that and folding that into our thinking. But I think that the honest answer is it's in the back of our minds. It's not necessarily on the forefront of our minds. We've been pretty busy trying to get some things redesigned and fielded and dealing with all the foibles surrounding that. I think the issue you raise is one that we even recognized in the paper that we gave to the Secretary but it's not one that we have really focused on to the extent that probably is necessary.
DR. STARFIELD: Does anybody want to follow up on that particular question?
MR. SCANLON: If I could just elaborate a little bit more, there's been a tradition to some extent, Kathy, over the years where some of our population based surveys would sometimes link with the claims history, for example, in the Medicare Program. I think one of the earlier medical expenditure panels and even the Health Interview Survey is capable of doing that.
So, starting from the point of view of a population based sample survey, there has been this approach of linking the claims history, Medicare claims history of that individual for analysis and research and those have been made public use data tapes as well.
The other end of this is really to the extent that we actually have a national provider ID and file, and it truly is complete, obviously that could be a sampling frame for other studies, it could help us think through some of what are these paying entities and provider entities now that the landscape is changing. So there's been some involvement in the past. There's really just sort of renewed effort now to see how it fits together.
DR. IEZZONI: One of the most productive linkages, Jim, I think has been the linkage of the SEER data, the NCI data on cancer incidence to the Medicare claims file that many people have used very productively to look at costs and experiences of patients with cancer. But that has taken resources. The NCI people and the HCFA people have done that themselves, but they've also elicited contracts from outside folks to do that.
I guess it kind of leads to my question about your resources. I see shoe strings kind of dangling all over here. I wonder to what point you feel you are at risk of kind of conducting surveys but simply not having the resources to be able to analyze the data to the fullest extent or make the best use of the data by, for example, for the Medicare beneficiaries linking it to claims files. Do you feel we're being penny wise and pound foolish?
MR. HUNTER: I will take that one. One of my responsibilities is to answer budget questions, so I should just say no comment and go on.
[Laughter.]
I think there are people who think we're no longer doing things on shoe strings, we're just down to wearing loafers and hoping it all stays on your feet. I think to say that we may reach a point where we can't take full advantage of what we've collected is to ignore that we're well past that point. I think there are many things we have in our existing surveys that we can't possibly mine. I mean it's why we've always put out public use tapes, but even that takes resources and they're not coming out as fast as one would like them to.
I guess I would echo your concern. I don't think there are large new dollars coming for things we're already doing and that is a concern. Any new resources that seem to come are coming for new very targeted initiatives. We've been successful at NCHS in returning our examination survey to the field, but it came with a box around the dollars for the examination survey while the Health Interview Survey itself from which the sample is drawn for the MEPS and in part of the HANES is flat lined and you hope you can find some efficiencies to keep it going.
On the earlier point, I think it ties to that, we certainly in the plan that was prepared for the Secretary a year and a half or so ago, the presumption was we had no interest in collecting information that we could get somewhere else. Certainly in the provider survey area, to the extent there are statewide hospital discharge systems that can do the same thing as our surveys do, and we're not really quite there yet, that would give way to getting information that's already available. We certainly had a lot of opportunity to think this through with the types of proposals that were made when the Health Security Act was debated, because that would have been a world of complete encounter data, and certainly we would have stopped doing a lot of things that we currently do.
What's hard to figure is when you're in this middle ground where you still need surveys because you can't get everything from administrative data and the administrative data is not complete, yet there are things if you put the two of them together you can get some real payoff. You have no resources to do that. It's really hard to figure out how you transition from the things you're now doing to the things you would like to do. I don't have any answer for that except, yes, it's a concern.
MR. ARNETT: The other thing I would say on that is as you put the data together, you make it more and more identifiable and therefore need to hold it back more and more. We've been exploring this notion of having data centers where people can come and actually touch and work with the confidential information and we monitor to make sure that nothing comes out of that that would expose people to disclosure, but even that takes resources. We started to think about setting up one for the MEPS data, and the amount of contractor resources we would have to make available to the people who would come in and rent a house near Rockville and work on this data turned out to be fairly significant and compete against the same resources we would use to run the survey. So it is a problem.
DR. LUMPKIN: First of all, I applaud you on your efforts to consolidate the surveys. I think there's certainly some great utility to that. To my mind, I think that we may not always as a country be as focused on the importance of data as we are now, I think our focus may be better in the future. So I certainly agree with your decision to have the data and spend the time maintaining the longitudinal capability to look at what's happening with the health of the people of this country when times are very short as opposed to necessarily mining the data.
This year, we saw an interesting phenomenon with the release of the movie Star Wars, which grossed more last week with almost all the other movies combined, even though it was a 20 year old film. There was one scene in there where off camera the voice of OB-1 kept on saying, "Use the force, use the force." I would like to echo that, because I would like to kind of say, "Use the states, use the states." I think that's really something that you mentioned somewhat about with the hospital discharge data sets. But there are a number of things that we may need to look at.
We appreciate the decision by Dr. Satcher to keep the Behavioral Risk Factor Survey at the state level. That's a very important thing because we in Illinois, for instance, are using our own money to expand that so we can get county level data and there's been a lot more focusing.
But as I was thinking about some of the surveys that you raised, particularly the provider and most notably the institutional providers, the hospitals, the nursing homes, we have somewhere in the neighborhood of about 300 nurses and sanitarians who go in those institutions almost on an annual basis, about 70 percent funded by HCFA. There may be a way to do some connection there. Once you make the trip out to Matune(?) to look at a nursing home in Illinois, you've spent most of the money you're going to expend on that particular activity. What you do once you're in that nursing home is really not increasingly expensive.
So there may be ways of looking at tying in some of the standards and quality stuff that's done at HCFA and by the states and licensing and so forth in collecting that sort of information. A number of states, for instance, we do an annual survey of hospitals and nursing homes and their finances that's done on a regular basis, where they get paid from, how much money, what's their profit level. We produce an annual report. There are other states I'm sure that are doing similar.
So I think to the extent we can look at leveraging some of the activities and the state may help collect some of the data, may allow it to be collected at a lower cost, and certainly to help us preserve this national resource which is the longitudinal study of health issues and health finance issues in the country.
MR. ARNETT: I think that's right. We have a couple of different things that we're doing with the states. Remember, you heard it here first, nothing is as simple as it seems like it should be. We do the age cup(?) data collection in 17 states and collect the hospital information, but we have 17 very stringent and quite different arrangements with the states on how we can handle and release that data. We approach states to talk to them about maybe doing a MEPS type survey within the states. We've been talking with three or four of them. Of course, none of them want exactly the same survey and from our perspective we would like them to be the same so we can aggregate them and have some sort of a detailed look that's comparable.
The other thing, of course, is that they don't want the state, they want all of the state market areas and, for example in California they want all 56 counties surveyed with a MEPS style survey which is $2,000 per case and you need to have a large enough sample to say something about each of the counties. And by the way, we don't have any money so we're hoping the government will do this for us.
And so, they don't say that, so we don't mean we shouldn't continue to pursue it because I think we have to, but it is very complicated and tough to see how it will all work together.
DR. LUMPKIN: If I might respond, I think you might want to explore more with the various associations, the epidemiologists, the -- I forget you guys new names -- the statisticians, as well as ASTO(?), because when you go and negotiate with the states, a state is obviously out there to cut its best deal. The national association may be willing to set a model standard and then try to sell that with you to various states. So that may be a way to get around the fact that if you come to me, I have tremendous needs and any way I can leverage what you're doing is in my best interest, but as an association that may be one of the ways to cut across that.
MR. VAN AMBURG: Can you talk a little bit more about how SLAITs will work?
DR. STARFIELD: I'm sorry, I didn't hear the question, George.
MR. VAN AMBURG: How SLAITs will work.
MR. HUNTER: SLAITs again is the telephone survey that we're building on the mechanism of the National Immunization Survey. I guess the concept is that, for those of you who aren't familiar, I will give 30 seconds on the Immunization Survey, somebody can time me. This is a survey that was developed for the National Immunization Program to monitor immunization trends in the 78 areas that are coincident with the immunization program areas. They're every state plus the major metropolitan areas, I think 25 of them and then you throw in D.C. and a couple of others. There are some that are not metropolitan areas, but anyhow 78 areas that cover the U.S. requiring a very large screening sample to find kids who are approximately two years old. So there's about 800,000 phone calls made where we connect with a household member, having already paid the cost of screening out all the businesses, all the fax numbers and so forth, in order to get 40,000 or 50,000 households with a child in the right age group. Believe it or not, it is the most efficient way to do this type of survey.
The obvious things is what do you do with the other 750,000 once you've paid the freight to get to the point of having a person there that's at least not hung up on you in the first place. So the idea was to take advantage of that large screening sample to, and we actually had this idea back when we thought we were going to be monitoring implementation of the Health Security Act or something like it, to just as if they have a two year old kid and then you branch off to a 20 minute interview on health insurance coverage, access to care, health status, things that we are drawing from the health interview survey, which is already sort of a compilation of sort of consensus data in a smattering of broad areas.
So the idea is that to the extent you can get these, for those things that you can get reliable answers on the phone and those things that the person is willing to answer on the phone, that you use this mechanism to do that. It's being developed and we're piloting it this year in I think about five states, possibly more.
The idea is to make it a very flexible type of mechanism where we can sample any number of different ways because we can use this 750,000 screener to fine tune down to different population groups. We can actually, since it's a random digit dial survey, you can target any geographic area, either the 78 or areas within that based on what we know about sociodemographics of the area.
Use something like the Health Interview Survey, a subsample of that, and also have the flexibility that a state could identify some relatively modest number of questions that may be unique to that state. We're offering in effect the panoply of questions that are on the HIS, and this is how we're trying to get the survey cleared, the questions that are on the HIS, the Current Population Survey, the SIP and a variety of other federal surveys that we can sort of take one from column A, one from column B. It could be used for sort of routine health tracking, it could be used for looking at some welfare reform related issues, it could be used for a whole variety -- it's almost neutral on content.
One last feature of it, but the last feature is because these questions are drawn largely from the National Health Interview Survey, as is the case with the Immunization Survey, we can make adjustments for those households that do not have phones, which is a major advantage over a direct screener done by phone. We actually know the difference in responses between those households with phones and those without from our direct household survey and can use those to adjust to the telephone coverage. More of an answer than you wanted probably.
DR. COHN: First of all, I should comment, is there something wrong with the microphone? We're hearing a lot of static over here in the corner. Whoever is in charge of that can fix that.
Having said that, first of all, I want to thank you very much for coming and talking about your integration work. I think that's very important, I applaud your activities. As a new member of the committee, I guess I would hope that at some point in the near future, as you begin to rethink the reasons for all the surveys and really what you're trying to find, I would personally really appreciate a presentation from you or some other communication around the objectives and outcomes of each of the pieces of the surveys so that maybe we could help brainstorm with you around alternate types of data that might help augment your work. I really do want to congratulate you on it, I think it's a very good effort.
MR. HUNTER: We will take you up on your suggestion.
DR. STARFIELD: I have a couple of questions. AHCPR has got another survey coming along, the Consumer Satisfaction. I don't know whether that's conceived of as a federal survey or something that's just going to go out to the market, but let's assume that. I suppose there are at least parts of that that could be incorporated into the HIS, MEPS. Is there any thinking?
MR. ARNETT: They are in fact, we do satisfaction questions in the MEPS, but can't get into any where near the depth that the CAPs(?) does. So what we did do is to coordinate the questions to make sure that they were comparable. Our intent is that as we get out of information out of one or the other of the surveys that we can cross walk. Obviously, if you wanted to have a lot more of an insight into what household satisfaction with their plan or their provider is, you're going to get it out of the CAP survey, but if you want to be able to relate that to their actual expenditures or use, you can get that out of the Health Interview or the MEPS survey.
DR. STARFIELD: My second question has to do with providers, usually when we talk about providers we almost always think about hospitals, but I actually want to think about the NAMSIs(?). Now I work a lot with the NAMSIs and I have the interesting experience of reviewers not having the vaguest idea what it is. They always are asking about generalization to consumer populations rather than to provider populations. So I would be interested to know what's your thinking about the utility of the provider survey is. I mean I think I know what the utility is from my point of view, but into the future, and whether or not we couldn't use some other way of getting at providers through the HIS MEPS to get at what NAMSI now does, but it's sort of isolated.
MR. HUNTER: Let me make one comment, I think the first thing we want to do in this conceptual framework project is ask those kinds of questions about what is it we're trying to learn from these surveys. I'm not sure exactly how you construct the matrix that leads you to it's no longer worth doing or it's critical to keep doing no matter what. But I think what we have in mind is asking basic questions like is this any longer useful to do. That goes across a number of things. It also brings in, and then it's compared to what else we can get somewhere else.
One other comment is back I don't know how many years now, five, seven years, we had the National Academy of Sciences do a panel on the National Health Care survey, which is the family of surveys that includes the Ambulatory Care Survey. They had proposed a sampling scheme where rather than doing independent frame samples of any of these providers, we would find these providers through the interview surveys, which had some features and turned out to have an awful lot of sampling problems.
One of the things I think we're going to want to look at is when we look at the joint field operations aspect of how do we approach providers, given that we're going from the MEPS and given that we may still go from provider frames, what does that do to sampling and are there some ways you can deal with that. Your question is probably more on other sources of data that don't involve sample surveys altogether, and I think that's something we probably will want to weigh as we look at whether these things are really the things we ought to be doing any more.
DR. STARFIELD: I think it's getting harder and harder to interpret the data from NAMSIs with providers working for so many different kinds of organizations and our need to understand that. You really can't get that out of the NAMSI survey.
MR. HUNTER: Actually Ross and I have had this discussion a lot about NAMSI has the induction interview where you learn something up front about the characteristics of the provider themselves, but it's almost, it's a forethought but it seems like it's almost an afterthought to the database which is primarily an encounter based data system. It almost seems sometimes like you need to take the hour you have with the physician and do a survey of the physicians to find out what they're doing, what their affiliations are, how they organize and practice. There's a lot of things that we wish we had that kind of a --
DR. STARFIELD: That's going to get increasingly more important. Almost nobody uses that kind of data because they don't know it's there.
MR. ARNETT: We are actually doing a prototype of the notion that Ed spoke about, ASPE and AHCPR are working with AMA, which is another novel thing to do, but developing a set of questions that can be used to determine the impact of the different financial incentives they're facing in their different practice settings and different reimbursement arrangements. I do think that it's important to do this with the AMA, because we're asking physicians about some fairly sensitive issues. I think they need to know that one of their partners is in this process. We do need to figure out how we can make it safe for them to give us the correct answers to these things.
DR. STARFIELD: Imagine how much money we're going to save when we've got a computerized patient record on everybody with a unique identifier.
MR. ARNETT: Yes, and a physician profile that's universally complete.
Ed was very diplomatic when he talked about a role that you could serve. I just want to make a probably more blunt plea. When we're dealing with this integration, it is very hard to get over the turf issues. I certainly feel them, and I think we all do. I do think that the committee has the potential to be an external, not involved, honest broker in looking at these issues and helping us sort them out. So I would really urge you to consider that thankless chore to say stand between AHCPR and HCFA and help us think through it more clearly and less from where we sit perspective.
DR. STARFIELD: That's our intent. Are there any other questions? Anyone else? If not, thank you very much and we look forward to seeing you again soon.
Now, I think we move to K2 Work Groups. We need to wait until John gets back for that.
DR. LUMPKIN: At this session, we're actually going to do this in a little bit of reverse order, which is I think we have a couple of things to discuss. One is the future activities of the K2 Work Group, what other things do we think we need to have hearings on. Then the second is sort of a recap of today and lessons learned. I'm kind of doing that in a backwards order, but we can dance around both issues if you want, mainly because Bob has to leave at 5:00. I just wanted him to be involved in that discussion about where we go from here.
The first issue that came up we had discussed at our last meeting about doing something on coding. I know Lisa has given a lot of thought to this.
DR. IEZZONI: Not that much thought actually, if you've seen my e-mails, I haven't been able to read any of your e-mails or thank you for them or respond to them.
Can I just point out to you all that very carefully during one of the breaks, you all received this document which is a draft of the charge to the HHS Work Team on Coding and Classification. I think it would be good for people to look at that. The plan had been to try to have the committee give feedback earlier rather than later. We should probably think through, John, some mechanism for us to just keep track of what the HHS Work Group on Coding and Classification is doing and make us be as constructive as possible to their process. DR. STARFIELD: This came from the Data Council?
DR. IEZZONI: No, this came from the Coding and Classification Implementation Team.
MR. MOORE: One of the five teams looking at the areas for standards.
DR. IEZZONI: One of the work groups, Donna Pickett, Pat Brooks, people from FDA, a bunch of places, Betsy Humphreys from the National Library of Medicine.
DR. LUMPKIN: And to help me, who is our liaison to that?
DR. IEZZONI: Well, I listened in on a first conference call, but it's obvious to me that I'm not -- I think the plan is to have weekly conference calls. I will probably not be able to listen in to every conference call. So I think we need to have a plan for how we're going to do this. We can maybe trade off listening in to conference calls, how should we raise issues that other members of the committee might want to be able to comment on, how can we be most constructive for the team. That's one issue. Then the other issue is the hearings on this particular topic. So I think those are actually two issues that we should discuss.
Let me just say that I did initially kind of get ownership of this simply because I talked a lot at the last meeting about this, but it has become very obvious to me that there are other people around the table who know just as much if not more than I do about many of the issues having to do with coding and classification. It was interesting when I sent around my e-mail to you all about what should we think about about the hearing to kind of generate discussion, for about four days there was silence, I didn't hear anything from you guys. All of a sudden, there were these wonderful kind of e-mails and communiques, lengthy attachments and it's obvious that people in their specific areas of interest, and we all on the committee represent different points of view and different expertise, everybody has feelings about this particular topic.
So, I think that what I would like to do is have this not be so Lisa directed as be more of a discussion right now about what we would like hearings to look like. I think that we should try to distinguish the issue of what we want hearings to look like from the ultimate issue that we are going to have to discuss as a work group which is what should we propose to the Secretary, because I think all of us have expertise and interests and long-term vested kind of time spent in doing particular aspects of coding and classification types of work. I think if we talk about that now, we're going to not get the information that we need for staff to get a hearing together in time.
DR. LUMPKIN: It seems to me, and I'm not necessarily the best one on coding either, but that there are three issues. One is those areas where there are competing coding sets where I think we may have to make a recommendation. The issue of how much granularity would we recommend in the coding set and we had some discussion on that. The second is the issue of whether or not the coding set, if we recommend the coding set, it can be used, or may providers have leeway to say I'm going to use this subset of that coding set and all my coders will have to use that as we see happening. So it's kind of whether or not there will be a uniform coding set and that's it and everybody can use it. The issue of granularity, should we go down to how many digits, and also the issue of competing ones. Those three things seem to be the ones we have to decide on.
DR. IEZZONI: And turn to the last page of this document, because there's a lot of coding sets. I think Simon actually called me on this. We have to be very clear what we mean by coding set for this discussion because I think as we are talking around the table each of us has something different in our brains about what we think we mean by this. This page seven, the glossary begins to kind of lay out for us how varied are coding sets having to do with medical classification and procedure classification, let alone all the other coding sets that we're going to have to deal with for other aspects of the data sets that we're going to be talking about.
So I think actually the first thing we should do is decide as a group what are going to be the boundaries around the hearing, let's just be very specific, the hearing that we're going to have. My recommendation would be to have it be medical and procedural, or clinical classification coding sets, because I think page seven shows us how big an issue that's going to be. But Simon will have a different point of view perhaps.
DR. COHN: Lisa and I had talked, and to just remind you I'm sort of serving as her backup on the committee, although --
DR. IEZZONI: I've already disavowed responsibility.
DR. COHN: No, I'm happy to have you be the lead. Lisa and I did talk. I was the one who didn't send an e-mail around to anybody about the code stuff only because she and I had talked so much. There really are two levels of issues. One is the code sets having to do with all of the transaction standards. I would comment that at least those of us who attended the last HISP meeting recognize that there are issues much beyond this medical classification of code sets that need to be dealt with in terms of the overall transaction standards. Indeed, though I don't see Bob Maze(?) here, I think that that's really one of the responsibilities of the infrastructure and cross cutting issues team, but if we don't somehow understand what those issues are and begin to understand how we need to be dealing with them and just immediately hone into medical classification, we will I think miss a tremendous opportunity to really move forward I think one of our basic objectives which is comparability of data at the end of the day. So I think that's an important issue.
Now, that is an issue slightly different than medical classification. I absolutely agree with you that we also need to do some hearings on medical classifications. I guess my feeling is that both of them somehow need to be accommodated in our view about code sets and all of that.
Now I would comment on one other thing. One of the papers that I passed around had to do with some recommendations from ANSI, HISB as well as CPRI, that there are conceptual issues that we maybe need to be thinking about or at least understand as we even approach this issue, because I think we need to be clear about what our options are sort of conceptually. We talk about granularity and yet we may need to look at this in a way where obviously one size does not fit all. We don't always want the most granular code, we don't always want the most summary code. We need to figure out how all of this might fit together in way to meet our end needs, having the right data at the right granularity.
DR. STARFIELD: Is there any way to sort of matrix this with the standard setting efforts? The standard setting groups are dealing in part with these, also with a lot of other things, but I'm thinking in terms of putting it altogether in a matrix so we can understand the relationships between standard setting and the code sets.
DR. IEZZONI: I think that's the broad issue of code sets that Simon was talking about and I don't know, has somebody done that, Simon?
DR. COHN: Well, I think that that's one of the areas that we need to explore. Now, as I said, once again breaking them up into different areas there are within the standards data sets and I am excluding medical classification, arguments about CPT-4 or ICD-9. But one of the things that we need to be doing is looking to see where the data fields are identified the same, the code set values are different, as well as where the data sets, the definitions are very slightly different and see if we can do some things to increase comparability.
DR. STARFIELD: We're not going to get this from hearings. Somebody is just going to --
DR. COHN: No, well we can ask --
MS. GREENBERG: That's the work that's going to be done by the implementation teams. I think it's important to understand what they're doing. This particular implementation team, the coding classification that Lisa and Simon volunteered for, their focus is medical classifications procedures and diagnoses. But just out of interest, have any of the other members had any contact from the -- there was some volunteering for the other teams, but I think it wasn't really brought to closure at the last meeting.
DR. COHN: Yes, Bob Maze and I have had an informal discussion.
MS. GREENBERG: You volunteered for the infrastructure, okay, because I really think that's going to be -- the Department is going to have to look at all those transactions and the code sets and where they differ. Then there are issues that I think they can bring to the committee, and furthermore if somebody has the opportunity to participate in some conference calls or whatever, they can identify issues, but it isn't something that the committee would have to do de novo.
DR. STARFIELD: But is it going to come soon enough to help us in our thinking?
MR. MOORE: I don't know what you mean, the transaction sets that are identified in the legislation, when we broke the teams into two teams working on the transaction sets themselves, within those transactions there were administrative codes like place of service, type of service, which I don't think require a special amount of expertise. We're going to get a lot of information from the SDOs as to what they've already worked through the hundreds of possibilities for those codes. We're going to use that as a starting point.
But on the medical classification, we felt that was a unique knowledge and skill over and above defining what do you use for sex, whether you use a one or a two or an M or F or whatever, and you go with different kinds of codes there and you look at what's being used in the industry today predominantly.
DR. IEZZONI: I do think that we can't lose track of what Simon has raised because it's a crucial issue, but I do think that we're about to get ourselves in Washington more than any of us can afford to be here if we have too many hearings. I think maybe as a full committee in March, we're going to have to think about how we're going to address all the pieces that we have to address to be able to meet our responsibilities, because it's a huge amount.
I think, however, the medical classification issue is a big enough piece and resonates with the users that we heard in our first panel this morning so much in terms of measuring quality of care, measuring outcomes, keeping track of what's going on in the health care system that it's probably worth having a hearing specific to this area.
John, in terms of the kind of folks that I think should probably need to be there are the people who produce the different classification systems, to just get them to talk to each other, to get some honest discussion about overlaps and about how things are updated, and just the procedures for making sure that codes keep pace with how we need to use them and the changes in medical knowledge and technology. The second thing is --
DR. STARFIELD: Can I just ask you, is this the responsible organization on this matrix, is that what you're referring to?
DR. IEZZONI: Not necessarily. Can I just pontificate for a second and then we can talk specifics. The second thing is I don't want to lose track of the fact that there's a need to classify medical conditions and human health conditions beyond in primary care and disability and impairments and functional status, beyond the standard kind of codes that we have in hospitals. The ICD-9CM works fine in hospitals, it doesn't work as well in nursing homes, home health, primary care and so on. I think we need people who are going to have to use data but might not have the standard kind of diagnosis mindset for how they classify what they want to classify.
Then the third kind of person I would like to have, I would love to have Kathy Coltin be on a panel because we need people who are users. I mean Kathy has spoken very eloquently about the implications of having multiple coding systems for procedures in trying to do the work that she does with Harvard Pilgrim Health Care to evaluate quality of care. So that would be the third group that I would like to see is I would like to hear from users about what they view as the strengths of different coding sets, what they view as the weaknesses, what they view as the challenges and how ultimately they would think about helping us think about our goal of simplification.
DR. LUMPKIN: Can you help me with the second group?
MS. GREENBERG: Yes, I missed the second group.
DR. IEZZONI: The second group was people in different practice settings who might not use the standard codes like people outside of hospitals, people in primary care, people from rehab, from nursing homes, from other settings of care, other than the standard -- the paradigm that we've had forever has been hospital based or acute practice, medical practice based primary care.
DR. LUMPKIN: It would seem to me that if we're talking about users of codes, there really are two users. There are N coders and D coders, data users, and we may want to get an idea from people who have to N code what the differences are in the systems. Do they feel that these coding sets, like ICD-9 I think there's like codes there for falling out of a space ship --
DR. IEZZONI: There are E codes, falling out of space ships.
DR. LUMPKIN: But there are other E codes for common things like falls in a house which you can't code for. So it's the kind of thing where do these coding sets seem to meet the needs of people who are trying to describe what it is that they've done or are doing.
DR. IEZZONI: That's a great distinction that needs to be made.
DR. COHN: Lisa, I agree with your groups. I guess I would add myself that I think there are a lot of people who have spent a lot of time trying to figure out how to put all of these things together. I can think of people like UMLS.
DR. IEZZONI: I think there's a conceptual framework, yes. We need a conceptual framework for all of this.
DR. COHN: And one panel who have had to deal with trying to figure out how these things come together would be very useful.
DR. IEZZONI: There's a comment in the audience.
MR. BLAIR: You just about hit it there, which was that in addition to the N codes and the D codes, as we begin to evolve towards computer based patient records and repositories and the need for medical data dictionaries or lexicons or whatever we want to call them, you begin to wind up having to reconcile these codes into a model of medical knowledge, whether you call it a framework or a model, there's got to be some way of keeping it cohesive and consistent. I think that that viewpoint is not necessarily represented by N coders and D coders and I would submit that that's a third group.
DR. IEZZONI: I agree, yes. I actually think something like that would be nice to do with the full committee, because the full committee is ultimately going to have to come up with the recommendations. It would be awfully nice as we're thinking about our conceptual model and where we're going down the road with this, thinking towards our mandate what the electronic medical record ultimately, to have that kind of discussion happen with the full committee.
DR. COHN: Lisa, just to make sure that I understand, so you're thinking that this actual hearing ought to be a full committee?
DR. IEZZONI: No, the conceptual framework piece ought to be the full committee, but then, yes I think the working group could do the developers and the users and the N coders and the D coders and that.
DR. LUMPKIN: So the people who are trying to put everything together, the NLMS systems.
DR. COHN: I think we can come up with names.
MS. GREENBERG: So you don't want to completely separate that from the people who are developing systems or responsible for systems who may have a different view on how things fit together and generally know more than their own system or certainly realize that they have to interact with these other systems. So I'm a little reluctant to have that be completely separated from those folks, because then you won't get the tension and the dialogue either.
DR. IEZZONI: But I'm also reluctant to have it be separate from the full committee, because I think the full committee is going to have to be the place where we make some really hard decisions. I anticipate that this particular topic is going to cause a lot of arguments, or discussion, let's be euphemistic about this. I think it's going to be important for the full committee to have heard some of this. I think I don't know whether the March meeting is completely booked for the full committee?
MS. GREENBERG: No, I think tomorrow the Executive Subcommittee is meeting and it's very timely if the subcommittee wants to recommend something.
DR. IEZZONI: That's what I was thinking is if we could have the full committee talk about the conceptual framework in March and then have a hearing in April, we would have learned something from the March that could allow us to ask really specific questions to the panelists for the hearing. I tend to be a very concrete person anyway. I would like to have our questions be very targeted for the hearings to try to elicit both areas of consensus, but also areas that we need to know about in which there's disagreement.
I think panelists tend to be very gracious, but I will tell you honestly that I have had people come up to me after the panels this morning and indicate that they had things that they wanted to say that were very targeted and very specific that we need to hear that are controversial. I think that we need to give people very specific opportunities to talk about things that might be controversial and feel that they can make arguments and have that kind of discussion.
DR. LUMPKIN: What I'm hearing then is perhaps we're talking about perhaps a session at the March meeting that would use those people who have some conceptual models be put in together and some of those users who also have some concept of how this all fits together, the D code users. Does that kind of describe --
DR. IEZZONI: I'm not sure, I think I would like to have -- I think we will have enough on our plate with the conceptual model people. I would like to have some of the users be able to react to some of the panelists who are the developers and the vendors of different systems.
MS. GREENBERG: Also, if enough people know that in some way this can be known that this is going to be at the March meeting followed by the April meeting, in a way it might be the way -- we started with certain groups and then ending up with the standards organizations. Those folks are probably going to want to come to the March meeting or send some people and participate from the audience, or at least be involved. So I think if it's well enough known, you will get users and other people too, not on the panel.
DR. IEZZONI: I would love to get from NCQA, I mean Kathy, the NCQA people have had a terrible time coming up with denominators. Jim Tierney talked about that a little bit this morning. Those are the kind of users that we need to hear from. I think though the conceptual framework is slightly different.
DR. STARFIELD: The NCQA just came out with a document.
DR. IEZZONI: Yes, it was an interesting, it was a nice document.
DR. STARFIELD: Within the last three or four days. Has it actually come out?
DR. IEZZONI: What Barbara is referring to is that NCQA did kind of an informal survey -- it's a draft. They did an informal survey of information people and have written it up, a very nice draft, yes.
DR. STARFIELD: I think it's dated the 7 of February if I'm not mistaken.
DR. IEZZONI: Yes, it was.
DR. COHN: Lisa, I was going to say I'm in complete agreement with you about the conceptual thing next time. I do think as I remember hearing some thoughts about the personal identifier also being on that plate for March. If that happens --
DR. STARFIELD: It's in this document.
DR. COHN: We're barely going to have enough time as it is, but the other one sounds very exciting.
DR. IEZZONI: I'm sorry, how do we get a hearing to happen? I mean how do we decide who we're going to invite? How do we help? I was going to say how do we tell staff what we want and make them do it for us? I don't want to be that bold about it? For the April meeting --
MS. GREENBERG: We had enough meetings set up in the past --
DR. IEZZONI: I know but for the April meeting, have we been -- because Marjorie, you wrote me an e-mail and you said that you wanted more clarity about what we wanted for the hearing before you felt comfortable going ahead. Is there enough clarity for staff to --
MS. GREENBERG: Let's talk about how we did it with these meetings. We met in Chicago before the ANSI-HIS, and we identified all the different kinds of groups, both groups and generic types of people. When people had names, those names were given. To the extent that we could, we got some agreement on how we wanted to set up the panels and then basically staff, Bill and Bob primarily started contacting those people.
DR. BRAITHWAITE: Name names and we go after them. MS. GREENBERG: Have names, we will call.
DR. IEZZONI: Well, I guess we heard the standard representatives of some organizations. I'm not sure that I necessarily want to hear the standard representatives again. Can we, like from some -- I'm trying to be careful here -- from some of the developers --
MR. MOORE: We're friends, you don't have to be careful.
DR. IEZZONI: But from some of the developers of the systems, like specifically the AMA. It would be nice to get somebody who is really in the trenches.
DR. BRAITHWAITE: You understand that our desire to get that person here doesn't --
DR. IEZZONI: Right, doesn't necessarily mean that that's who we're going to get, right.
DR. LUMPKIN: Also, one of the things we ran into with the first one and the second one, there are people who we wanted to get in broad classifications, and when we said administrative simplification, they said you mean that applies to us. So they weren't ready to testify. I think we've got that problem too, that just because we want to hear from them doesn't mean that they're ready to say what it is that they have to say yet. We just have to temper that. We will try.
MR. MOORE: That's also the amount of time that we give them. Bill and I were calling people last week for this week. We need to give more time for them, and some of them weren't comfortable coming here this week saying something in public that's going to get recorded and fed back to them and they would rather wait.
DR. COHN: I actually personally think that the code set developers which I describe differently than standards developers, code sets are not standards to my knowledge. I mean once again, it depends on what your definition of standards is, but my definition of standards is developed by an ANSI-accredited standards body. I don't know of any code set that's a standard by that definition. So I find the code set developers -- Marjorie may take offense here --
MS. GREENBERG: That's not the only definition of standards, but in this arena --
DR. COHN: In this room for the moment, I think that they're a little less shy about discussing --
DR. IEZZONI: I was going to say so too, I think they will be less shy about talking about their --
DR. COHN: I think there's plenty they have to talk about which I think we would find very interesting. I do agree with Bob that we need to give people enough advance notice. It probably means trying to come up with the dates today if we can, the April meeting so people can begin to think about it.
DR. BRAITHWAITE: Name dates, name names and we will go forward.
DR. COHN: Maybe that's what we should do now is just come up with dates that we agree on as possible dates for this. If that's okay with Marjorie and Jim.
DR. IEZZONI: Some of us don't have our calendars.
MS. GREENBERG: We will follow up obviously, but maybe we could at least identify some possibilities in April.
[Discussion of possible dates.]
MR. MOORE: The 23 to the 25 I will be in Tysons Corner presenting for three days the implementation guides for all nine of those transaction sets and getting public discussion on that. I expect a lot of the federal people who are working on these teams to be down there listening to that. I've given those guys a lot of grief.
MS. GREENBERG: Okay, the 23 to the 25 you said? How does the week of the 14 look to people?
DR. IEZZONI: I don't know.
MS. GREENBERG: Are you thinking of one or two days, a day and a half?
DR. IEZZONI: What would be nice is if we could start at 10:00 in the morning so people could maybe fly in the morning of and then -- I know it's bad for poor Simon.
DR. COHN: It doesn't matter to me.
DR. IEZZONI: But it will work for John. Then break the next day around 12:30 or 1:00, so a day and a half.
DR. COHN: I guess the question then is, and I think what you're describing is absolutely fine, but I have about four or five other items here that we need to somehow handle. Is that a whole other set of hearings? Should I just mention what I had noted as other things that we need to handle somewhere?
One has to do with state examples of standards implementation, which is an ongoing issue that we need to deal with and probably not in the real distant future. We need at some point to be able to start dealing with claims attachments. I don't know if our personal identifier issue is going to be solved at the March meeting, but --
[Laughter.]
That would be great. I just mention those because I made notes of these being issues that we already identified as ongoing issues. Do we try to tack it on to this?
MS. GREENBERG: What's the first one, Simon?
DR. COHN: State examples -- a number of states have actually implemented standards.
MS. GREENBERG: And several people have recommended that. I really think we would be remiss not doing that.
DR. COHN: Yes, so I'm happy to have that be a later set of hearings, but we just need to be aware that were not solved, were not handled by the time we finish up codes.
DR. LUMPKIN: I'm sorry, you had three?
DR. COHN: Yes, I had claims attachment was the third.
MS. GREENBERG: A little more time on the claims attachment than we do on the other --
DR. COHN: Yes, 12 months, I mean that's the good part of that.
MS. GREENBERG: Also, since the Executive Subcommittee is meeting tomorrow after this meeting, if anyone who is not going to be there has some suggestions about the panel on personal identifiers, please come forward. I mean you probably have some of the ones that we all know about but you might have some others.
DR. LUMPKIN: Yes, CPRI and WEDI ought to be two representative agencies.
MS. GREENBERG: Maybe ASTM also.
DR. STARFIELD: I think NCQD: I think NCQA -- are we talking about the personal identifiers?
MS. GREENBERG: I think almost everybody who has spoken in these hearings has talked about the importance of having the personal identifier.
DR. BRAITHWAITE: Are we going to let the Privacy Subcommittee deal with that issue at least from the policy perspective and then we can worry about the technical aspects once they've resolved that.
MR. MOORE: Out of the hearings and out of the requirements that the Secretary is going to give to Congress in August, we will then be able to say where we can go with the personal identifier.
MS. GREENBERG: Don wanted to have this on the agenda, but I think the idea was what are our options for a personal identifier once we've figured out how to protect it and so I don't think this is less having people come forward and say why they need it. I think the case has been made, although it clearly will have to be made better probably to the American public, what some of the options are or whether there are many options.
MR. MOORE: I think we've heard a lot about options over the last couple of years.
DR. BRAITHWAITE: It all hinges on the balance of the privacy policy questions, which is why we're kind of delaying with that one.
DR. LUMPKIN: But I think there are two questions. One is should we do it, although Congress said we should.
DR. BRAITHWAITE: You will do it.
DR. LUMPKIN: But that doesn't mean that they won't change their mind. Then the second question is if we're going to do it how do we do it. I think we perhaps need to focus this on how do we do it, which will then allow us to get into the issue of should and would because Congress will have the time to decide whether or not they're really serious.
DR. COHN: So you're saying that's for the large committee to focus on that topic?
DR. LUMPKIN: Right. I think the issue of kind of waiting until the confidentiality stuff gets done is perhaps pertinent for should we do it, but in the meantime we can discuss how we would do it if we were to do it, which is the more technical component of it.
Okay, so that leaves us -- I think if we do personal identifiers at the March meeting, and we're going to do codes at the March meeting and at the April meeting, that could leave us perhaps at the June or July meeting where we would look at state examples and claims attachments.
MR. MOORE: In order, just one point of order, in order to get everything done by February of next year, I have to have all the information in so that we can present to the Department sometime in the summer just what all the options are, this summer, because come October, I have to write a reg that's a draft that's out for publication. To get it to that point in October, I have to get it through all of the Department, all of the other federal agencies, through OMB and it took seven weeks to get that little three-pager through the Department and have it agreed, all the wordsmithing that gets done so that it's for public consumption. We're talking about 10 transactions, four identifiers, security standards. I'm dead in the water.
DR. LUMPKIN: Let me see if I understand this, because what we're really talking about, we've had hearings on the transaction sets, we've gone through a series of hearings on that, at the March meeting we will talk about personal identifiers and coding sets, which we will finish up in April. I think that gets you most of what you need.
DR. BRAITHWAITE: No, John, that gets you most of what you need, and you have to write the recommendations to the Secretary.
MR. MOORE: I'm afraid I might be working on those recommendations along with the other piece.
DR. LUMPKIN: Obviously, there will need to be a meeting of the full committee sometime --
MS. GREENBERG: There is one scheduled for June, late June, the 24th and 25th.
DR. LUMPKIN: Now, the time frame for claims attachments --
DR. COHN: Is afterwards.
DR. LUMPKIN: Is later, and the state examples will be useful as we start figuring out what all this stuff means. So I'm not sure that those two issues have an impact upon your time frame, the kinds of hearings that we need to have to have impact on your time frame should be completed by that June meeting, unless we're missing something.
MR. SCANLON: The state examples might help in terms of how successful they were when they chose some of these standards. That might be an earlier --
DR. LUMPKIN: We may want to graft that on then on the April hearing.
DR. COHN: I'm hearing this, I'm wondering, I guess we will have to see whether it should be an April meeting or whether there should be a late May or early June, with the state examples, as well as potentially I guess these transaction code sets if we have some analysis back by that time from HHS. Bob, if you're describing to me an accelerated time frame for work to be done, it might be a time for us to weigh in on those two. Of course, late May, early June would be a very good time to hear that and then begin to synthesize our findings.
DR. LUMPKIN: The question then becomes if we're looking at those time frames for the state examples if we can identify appropriate states, could we ask them to give us a three or four page briefing paper on their experience. Then do that rather than a hearing.
DR. STARFIELD: That's a good idea.
MS. GREENBERG: But not actually interact with them directly.
DR. STARFIELD: We can send them back questions I think.
DR. LUMPKIN: The only thing is we've got a certain amount of time before that June committee meeting, and --
MS. GREENBERG: It is difficult too often for people from the states to travel. That's a challenge, both the cost of the travel and just the traveling out of state, as George can certainly attest to that.
DR. STARFIELD: We can give them things that we would like the to include.
DR. COHN: I guess we really want a letter out to them saying what standards have they implemented, how successful has it been and learnings that they would like to share with us.
DR. STARFIELD: We're talking really about a half a dozen states maybe, or are there more?
MR. SCANLON: I can't don't know. It's not more than that. Minnesota for example. I don't think it's standard enough, we were talking to the folks from Minnesota, it doesn't seem to be quite the sort of thing where you can just write up something. It's legislation, it's hearings, it's standards and where they are. Actually, the interaction would be useful. We could try, we could ask them for a write up of what they've done, but they all went at it a little differently and they're at different places.
DR. LUMPKIN: Could we perhaps try to spend a half a day in April at the coding meeting then?
MR. SCANLON: Maybe get the four states in and just have -- we could try for that. Lisa, what do you think?
DR. IEZZONI: I think we're going to have a lot on our plate with the coding meeting. People's interest definitely wanes after --
DR. LUMPKIN: The difficulty then it would mean that we would want to do something in April and then either May or early June. Is that what we want to do? May is out for me because that's our last month for the legislature, so it's very hard for me to travel out of state.
DR. COHN: The very beginning of June would be fine, assuming you're still alive by that time, if that's your budget month.
DR. LUMPKIN: I can always be busy looking for a job.
DR. COHN: What I'm hearing is we ought to send them a letter and see what we get back. Then at that point, we can decide based on the response we get to questions that have been posed to them. Is that everyone's consensus?
DR. IEZZONI: Could we maybe have a phone call before hand to just explore with them, because I hear what you're saying that each of them is different?
MR. SCANLON: I'm not sure any of them have really gotten to the point where they have a standard working. What about the idea of the state --
DR. IEZZONI: Right, I know, that's what I'm wondering. The emperor might not have any clothes.
MR. SCANLON: -- some sort of having a state discussion at the full committee meeting just to talk about -- get some sense of what the states went through in terms of legislation or is that --
DR. LUMPKIN: You mean in June?
MR. SCANLON: Well, March. We would have to give up one of the others, I'm sure, we could do --
DR. LUMPKIN: I think we're talking about doing the overview of codes and personal identifiers in March --
MS. GREENBERG: And committee business, and then we have to have breakout sessions for the subcommittees. I really don't think we could have another chunk of time.
DR. LUMPKIN: Okay, so let me see if I understand this. April we're going to do the rest of coding. We're going to try to set something up in early June to do the states and --
MS. GREENBERG: Or an alternative was to ask for some written material and then decide based on that whether --
DR. LUMPKIN: Okay, let's do that, let's ask for some materials from the states, let's take a look at it, let's do a conference call and decide if we want to go ahead with the hearing based upon that.
DR. COHN: John, I was going to say, I personally feel the code discussion, the conceptualization at March is very, very important. I think it's a very vexing issue that we need to get a better handle on conceptually. Whether or not the Executive Committee decides that they want to talk about personal identifiers in March or about the examples I would leave to the Executive Committee because I think that that's -- it's certainly an area we need to talk about but somehow doesn't seem to be quite as hot an area as we're trying to deal with right now with these transaction standards. I will defer to you on that and the others on the Executive Committee. I don't know how everybody else feels about that.
MS. GREENBERG: We need to identify people for the conceptual framework discussion in March. I don't know if you want to do it now or through e-mail. We've got people in the room here. We're also meeting tomorrow morning, but I think you're not going to be here.
DR. COHN: I'm not going to be here. I would name off I guess two names, one is Betsy Humphreys or her designate from the UMLS and then Dr. Christopher Chute(?) from Mayo Foundation.
DR. STARFIELD: What's the name?
DR. COHN: Christopher Chute, and obviously others. Those certainly come very high on the list.
MS. GREENBERG: If anyone has any other thoughts, obviously they came immediately to mind. Anybody the committee hasn't heard from but who has been -- well, obviously some of the committee members, a number of you have a lot to offer in this.
DR. COHN: It may be useful to hear from the National Center around ICD, might be appropriate.
DR. STARFIELD: Do you want to do that, do you want to get perhaps the ICPD people --
DR. COHN: Yes, that gets down to our April meeting.
DR. IEZZONI: This was more the conceptual framework.
MS. COLTIN: I don't have a name to suggest, but I have an issue that I would like to hear somebody talk about it at the conceptual level, and that is the distinction between and appropriateness and need for a classification system versus a coding system, because we use those terms interchangeably and they're not necessarily. A classification system is generally also a coding system, but a coding system isn't necessarily a classification system.
DR. COHN: I think actually one of the papers I handed out actually makes some distinctions around that, but I think Dr. Chute might be very appropriate for some of these. He's academically well versed in this area, nosology and all.
MS. GREENBERG: Why don't people send e-mails on this if you have other ideas.
DR. STARFIELD: It would be helpful to have the specific questions when you think about people. Could we get those soon, could we generate those?
MS. GREENBERG: You all really need to discuss that, what questions you want asked, which is pretty much I guess what we did with the K2 as well. Then we kind of --
DR. LUMPKIN: What I'm hearing though is that we want some framework so that we can understand -- one is the difference between classification and coding systems, but the second is how does this all fit together. We're really perhaps less specific because we don't have a good framework, so we're looking for some of the gurus(?).
MS. COLTIN: The other point that I made in my e-mail to Lisa had to do with the purpose of the coding or classification system. I guess this gets back to what we were talking about earlier with regard to the survey effort and going back and saying what are the questions we're trying to answer with these surveys. I think we have to say what are the purposes we're trying to support with these coding systems because the coding system that best supports billing may not be the coding system that best supports clinical transactions. So I think we need to be able to weigh these various systems in terms of the purpose that they support.
DR. COHN: Other things that we need to have -- from my own view, it's probably the same question which is I think my hope is that some of them may shed some light about ways that apparently irreconcilable systems can be put together in a way that seems a little less conflicting and causing problems, as well as point out to us where there are real problems or principles we need to approach this with. That's probably the same thing we said to begin with.
MS. GREENBERG: It isn't really too early to start thinking about at least whom you want to invite to the April meeting and even some preliminary questions, because April is always a -- every month is a busy month now it seems, but at least you could give these organizations, we can give them a heads-up even if we don't have all the questions that you want answered defined. I wouldn't want to wait until after the March meeting to even start contacting them. Some of them are obvious, but do you want to hear from everybody on the matrix?
DR. IEZZONI: I think we want to hear from a lot of them but obviously we can't hear from everybody. I'm just concerned because we're not meeting John's target for what else we have to talk about. Maybe we could e-mail, Marjorie, why don't we send out an e-mail just trying to solicit names and suggestions for the April meeting and ask people to get back within a week with suggestions.
DR. STARFIELD: I would have trouble doing that without knowing what the questions were.
DR. IEZZONI: Oh, for the April meeting, the people who developed the methods, the people who use them but in non-standard settings, and the users.
DR. LUMPKIN: I think the questions ought to be different for each group. I think for the people who produce the codes, and again I don't think we want to get all the folks on the matrix, we just want those -- I think we want to focus in on the medical description of disease and the procedural codes --
MS. GREENBERG: That's pretty much what's on here
DR. IEZZONI: How about the ICIDH?
DR. LUMPKIN: There are two kinds of issues. One is where are there gaps and where are there overlaps. We're going to have to resolve the overlaps and we're going to have to identify the gaps. So the panel on users, the people in different practice settings, that's where we expect to get the gaps. In the current coding systems, where are the gaps, where are the things that you do that can't be coded in any of the systems, or conversely, of the coding systems that are there, which one can you code your stuff in better. So those would be the kinds of questions that we would expect them to ask, what's your practice environment.
For the people who produce the codes, what is your organizational commitment to maintain those codes, how do you reach out to other people in assuring that codes are added in an ongoing basis so we can compare the viability of the coding structures, the changeability, the responsiveness to the different coding systems. If we go for an ICD-9, 10 procedure code, do we get the feeling it's going to be as concurrent as the CPT? Those are the kinds of issues I think we need to ask them about.
MS. COLTIN: I would also ask a purpose question, what are the purposes the system is intended to serve. I would ask them to identify some of their strengths and weaknesses in serving each of those purposes. I would like to hear their perspective on it as well as the user perspective.
DR. COHN: I think also a very fundamental question for the developers is what they feel their applicability of their code set is to administrative transactions, since that's our first step, and then extensibility to future transactions, the computer based patient record pieces.
DR. LUMPKIN: And then we have the N coders and D coders, the users --
DR. COHN: Should we get your wife?
DR. LUMPKIN: No, maybe her billing person in her office. But I think the same question is what's the utility of these codes, do you think they fairly represent -- it's very similar to what we would ask the people in different practice settings. Do these codes meet your needs, are there gaps, are there overlaps?
DR. IEZZONI: How do you deal with multiplicity of codes.
DR. LUMPKIN: That's right, how do you deal with them. Do you feel that there is utility and multiplicity of codes? How many multiple code sets, I mean is it the second one that's the biggest burden or is the third the fourth, those kind of issues. If we could perhaps start out with that and then get some feedback and additional questions, refinement, I think that's sort of --
MS. GREENBERG: I can, it's tit for tat in a way, but often staff do send things out and there is this great silence. So given the time frame, et cetera, we proceed. But I do encourage you to respond and to input. Any of these will only be as useful to you as we're getting the right people and asking the questions you're interested in.
DR. COHN: Marjorie, I guess I should ask, I thought you were actually addressing a different issue, that you were sending letters out to people and inviting them and there was a great silence, as opposed to us, which --
MS. GREENBERG: We don't allow them to be silent, we badger them.
DR. COHN: I guess the question is do you need our help to ensure that the right people are at the April meeting or at the March meeting for the sessions?
MS. GREENBERG: We will feel free to call on you, right?
DR. COHN: I'm sure Lisa volunteers, I know I do.
DR. LUMPKIN: Thank you.
DR. IEZZONI: We still have the issue of how we're going to be maximally useful and productive in participating with or knowing about the coding and classification implementation team that HHS has ongoing. Again, they're going to have weekly conference calls. I'm not going to be able to listen in to each of those.
DR. COHN: I will try to help as a back up to you when you're not available.
DR. IEZZONI: Do people want to see -- I'm not sure whether it's politically even feasible to have drafts of the various documents that the group has developed, do people want to see those? What type of involvement do we want to have?
DR. COHN: Lisa, I think just to elevate your question, because the question should be asked by each of us, in relationship to all of the implementation teams. You're in a position where at least you've been on a conference call.
DR. IEZZONI: I listened, I didn't say anything.
DR. COHN: I am part of the infrastructure team and I've had one informal conversation. I don't know how the others have done. You've had nothing, the identifiers. Lisa, what you're really asking is the norms of how do we -- are we going to be sharing the information back and forth and if so, how?
DR. IEZZONI: What was obvious to me on the conference call is that these teams are marching forward at a pace. They had done a lot of thinking, this was their first conference call, they had done a lot of thinking. They know the dates, they know the deadlines, they know what they need to do by this time. So it's not as if they're waiting to hear what the National Committee has to say. I'm sure they would welcome our input, but they have a job to do.
DR. LUMPKIN: I think they have a job to do and we will have a job to do. Our task on the work group is to make those two time lines merge. So my response would be I don't think that there is a real feasible way for any of us to participate any more than we are.
DR. IEZZONI: I agree.
DR. LUMPKIN: But that the two people on the coding, you need to have some assessment when you think there's something being produced or something that's important for the rest of us to hear, to make sure that copy then of that stage is shared with the rest of the work group.
DR. IEZZONI: It's the charge. That's the first document I think everybody needs to look at.
DR. LUMPKIN: Then we need to respond to you to let you know and then you can feed it back to the work group so we're all trying to at least keep tabs of where we are. If there are issues that you think are fundamental that you have with the coding issues, all of us need to raise those as being key issues. We need to be ready in June to make some decisions. The work of the liaisons is to make sure that the issues are brought to the work group and the committee before June so that we will be ready to make those decisions.
MS. COLTIN: I would find it helpful if the implementation teams have laid out time lines with particular tasks, or some sort of a work plan to see that because it would be helpful in saying this is the point at which I would like to have some input or I would like to hear something, but I don't need to be involved every step along the way.
MS. PICKETT: As Lisa indicated, our first meeting was Thursday. We tried to do a fast turnaround with the information that was discussed at that meeting so you could have it in front of you today. Our next meeting is set for this coming Thursday where the group will be reviewing the draft, because again, this was all basically conceptualized during the discussion. All of the team members were not able to participate and some of the documents that we've been trying to transmit to all of our team members we've had less than wonderful success with some of modern technology in getting some of those documents out to everyone. For those that did make it over, printing out 200 pages of documentation when you only have one printer at your given agency has proven to be rather interesting. We've developed new ways of sharing information so that everyone that's part of the team, if they can't receive it electronically will at least receive it via paper so they will have something.
Again, the charge that you have here and the matrix that was developed to go with it basically was kind of laying out where conceptually we thought the team will be heading, but it will be rediscussed and mashed around a little bit more, as have the other charges from the other implementation teams. Everything has been very fluid in terms of having input not only from within the team but from other teams as well as they've worked on some of this information.
So again, this will go back to this Thursday's meeting. We were charged with developing time frames and trying to work all of those things in, but that will be part of the next step. We do have a massive task. I don't know if you could hear me from the back when everyone was talking about the long list and the glossary, please don't think that everything you see in this matrix is it. It is not it. The team members have identified other things that we need to place on the list.
The grid that you have actually is in two parts. There's a long-term list which really is more in keeping with the computer based patient record, and the short-term list as we're calling it is basically for the administrative transactions. We feel that we will probably be adding more to each list, but that is just to help us look at what is out there. Some of the things, as you see, there's a column on there referencing ANSI-HISB inventory so for those things that are also part of that list, we've referenced it here just to see where it has been picked up in other inventories that we are aware of.
What we hope to do at some point, and the team members are assisting in this process, is filling in the blanks that are currently in the cell. And so at the next meeting, we're hoping, or when I get back to the office on Wednesday, I hope to find a bunch of e-mails there with a lot of the data that we discussed during that conference call that we know is missing, but again this was just the beginning of the framework and not meant to be a final product. We feel that this is going to be very fluid as well and that there are probably going to be other pieces of data added to this so that we can really look at what are some of the other issues that are not already identified on this. So the page may start to grow this way when we start adding on comments and other users and other issues that have been discussed by the presenters this morning and during this discussion this afternoon.
DR. COHN: Okay, can I just make one comment? Just a very brief preview of all of this, I presume that we will be sending you, or should be sending you missed classifications, nomenclatures and vocabularies that you've not included.
MS. PICKETT: Again, we know there were some that we missed, again we were trying to turn this around so that the work group had it for their first discussion. But yes, we do have tons, but if you think we've missed something or it's not something that would immediately become apparent to us, send it anyway.
DR. COHN: Okay. I think that the main issue we need to be dealing with I think today is the charge and any comments about specific objectives. Just a casual reading of the specific objectives made me wonder about item five, what I describe as the conceptualization here that somehow recommended health vocabularies are different from standard codes and classifications. I think that's really a conceptualization issue that once again I would hope we get a little clearer at our March meeting, but I actually tend to think is an error just because I think that a recommended health vocabulary is effectively the same as a code as a classification, as a nomenclature and this somehow considering them to be separate maybe a mistake. That would be my, as I look at this, otherwise I think it's fine.
MS. GREENBERG: How do you want to deal with comments? I think the idea of using the point people is a good one rather than the implementation teams having to deal with 16 different members or 18 different members of the committee.
DR. COHN: I guess we should send it to the lead person.
MS. GREENBERG: Let Lisa know if you have issues or do you want to discuss it. I think people are probably kind of losing it here.
DR. LUMPKIN: I think that kind of comment, perhaps we need to expand upon it, because I know exactly where that came from and who it came from and she probably would need to see a little bit more of your reasoning why you think it's wrong.
DR. COHN: Oh, you mean that there's a difference between standard codes and classifications versus health terminologies or vocabularies?
DR. LUMPKIN: Yes, I'm sure that came right from NLM.
MS. PICKETT: Point number five really was to try to look at, since we're talking about something that's more immediate in terms of the transactions and then the longer term for the computer based patient record, that there would be a mapping, a well thought out defined process for doing that and not something you do after the fact. But if you think the language isn't clear or there needs to be something else here --
DR. COHN: Maybe you should tell me who gave you that wording and I can have a discussion with that person. I think the concept that you want to have a health vocabulary, what you're really talking about a controlled health care vocabulary, which already is effectively, whether it's represented by a number, which is a code is essentially the same thing as a code or a classification. I think that was really the thing I was responding to here that -- I'm not sure in my mind in sort of, in the world of the year 2000 really a difference. Am I making myself clear, Bill?
DR. BRAITHWAITE: Simon, I suspect that many people would agree with you about the control vocabulary when it's represented by a code is the same thing, but they think about classification systems as ways of aggregating those controlled vocabulary terms which tend to be focused on representing unique concepts. When you aggregate them for some purpose, then you end up with a classification system.
MS. GREENBERG(?): You need to be able to go between the two.
DR. BRAITHWAITE: You need to be able to map one to the other.
DR. COHN: Yes, I guess what your describing is synonyms and things like that.
DR. BRAITHWAITE: No, we're describing statistically meaningful aggregates. You don't want --
DR. COHN: You're talking about issues of granularity and aggregation now.
DR. BRAITHWAITE: Right, and that's what classification refers to in this statement I think.
DR. COHN: As I look at this, you're probably right, though why they throw standard codes and classifications in the same thing I guess I would have a question about that. I think that the real question gets to be whether or not health vocabularies include nongranular items which are then the same as -- this is I think the conceptual issue I was describing, which we may have better vision about in March about how we want to approach this thing. I think it's just an issue that looked to me like -- I believed this to be wrong personally, but the subcommittee or committee would have to --
DR. BRAITHWAITE: The integrated framework is a much better approach, but then you're going to have to explain that to everybody.
DR. LUMPKIN: So I think this may be another issue for March, the difference between -- point five, whether or not point five is right. We can charge each of our --
DR. BRAITHWAITE: That was Katherine's question actually. It's already on the list.
MS. GREENBERG: You still want to meet tomorrow morning at 8:00?
DR. LUMPKIN: Right.
MR. SCANLON: One other item for March. Don wanted to know if the subcommittee would want to make a recommendation or some discussion on the national provider inventory at the full meeting in March, the national provider ID. It could be in terms of concept and framework and principle, he wanted to know if the subcommittee would want to at least come back to the full committee with some --
DR. LUMPKIN: I think we ought to have one.
DR. STARFIELD: We need a few minutes tomorrow to talk about documents.
DR. LUMPKIN: So we're going to meet at 8:00 tomorrow morning except for Simon who will be on his way. Okay. Do we have other stuff we need to --
DR. BRAITHWAITE: It just has to do with people who will be joining us for dinner tonight after we adjourn the meeting just so they know where it is.
DR. LUMPKIN: Okay.
[Whereupon the meeting recessed, to reconvene the following day, Tuesday, February 11, at 8:00 a.m.]