[This Transcript is Unedited]
Hubert H. Humphrey Building
Room 800
200 Independence Avenue, S.W.
Washington, D.C. 20201
DR. COHN: Good morning. Can we get started now? I want to call this meeting to order. This is the first day of hearings on the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics.
I think as you all know this committee is the main public advisory committee in the U.S. Department of Health and Human Services on national health information policy. I am Simon Cohn, chairman of the subcommittee. I am also the national director for health information policy for Kaiser Permanente.
I want to welcome fellow subcommittee members, HHS staff and others here in person. I want to also remind everyone just at the beginning that we are on the Internet for this day of hearings and, therefore, I would ask everyone to speak into the microphone and I need to remind myself to do that from time to time and also speak clearly.
Today is the first of several hearings planned for the remainder of 2002 and into the first half of 2003 on patient medical record information terminologies. Our intent is by next year is to be able to make recommendations to the Secretary for next steps related to national standards in this area.
The focus today is on the scope of our efforts and on criteria we should be using. Tomorrow we will have other issues we will be talking about and we will be starting, I believe, at 8:30 in the morning. This will include discussions with other public and private and federal consortia on these and other PMRI standards.
In the afternoon, we will be having further discussions on ICD-10 and also issues related to DSM-4, both in relationship -- the latter in relationship to HIPAA issues.
I want to thank Jeff Blair, my vice chair, I guess, for his work and leadership in terms of putting today's hearings together and generally his leadership in the whole area of PMRI standards activities. Obviously, without his leadership, we would not be having this hearing today.
We also want to thank Steve Steindel, Donna Pickett, Suzie Bebee and Michael Fitzmaurice for their work putting this thing together.
With that, let's have introductions around the room, starting with the subcommittee members first around the table and then we will be asking those in attendance also to identify yourselves. For those who are on the subcommittee, I would ask if there are any issues coming before you today from which you need to accuse yourself because of any possible or potential conflict of interest.
With that, Jeff, would you like to start off with the introductions?
MR. BLAIR: I am Jeff Blair. I am vice president of the Medical Records Institute, vice chair of the Subcommittee on Standards and Security here at the NCVHS.
I don't feel like I have anything to recuse myself of; however, I do want to mention that I am a member of HL7, of INSUS. Five or six years ago, I did have a consulting engagement with SNOMED and SNOMED has sponsored some activities that I am involved with at PMRI. I have also been a member of ASTM and a member of ANSI HISB.
MR. AUGUSTINE: Brady Augustine, Gambro Healthcare, corporate director for special projects, senior biostatistician and medical economist. I have no conflicts. I am a member of the subcommittee and a member of the full committee.
DR. FITZMAURICE: Michael Fitzmaurice, senior science advisor for information technology at the Agency for Healthcare Research and Quality. I am lead staff on the Secretary's Council on Private Sector Initiatives to improve Security, Safety and Quality of Healthcare. I am liaison to the National Committee. I am staff to the Subcommittee on Standards and Security. My agency supports the meetings of the ANSI Health Informatics Standards Board.
MS. BEBEE: I am Susie Bebee. I am a health informatics specialist with the National Center for Health Statistics and I am staff to the subcommittee.
MS. GREENBERG: I am Marjorie Greenberg from the National Center for Health Statistics, Centers for Disease Control and Prevention and the executive secretary to the committee.
MR. STEINDEL: Steve Steindel, Centers for Disease Control and Prevention, staff to the subcommittee.
MR. SCANLON: Good morning. I am Jim Scanlon. I am with the HHS Office of Planning and Evaluation, Office of Science and Data Policy. I am the executive staff director for the committee.
In that capacity, I would really like to introduce to my right Dr. Bill Yasnoff, who has joined our office in ASPI, as a senior advisor for NHII issues. He will be -- started yesterday. So, he is just getting used to the offices here. But he will be helping us think through and provide technical and other advice on the NHII standards and a variety of related issues.
DR. YASNOFF: Bill Yasnoff, senior advisor, National Health Information Infrastructure, ASPI, HHS and glad to be here with you in this new capacity and look forward to working with you.
DR. COHN: I guess I should -- before we continue the introductions, I think we all want to congratulate Dr. Yasnoff on his new role.
[Applause.]
For those of you who are familiar with the subcommittee, I think you will all be aware that Dr. Yasnoff has been a participant in these activities for a number of years now and we are happy to have you back with us. Hopefully, this will not be just one time that you are joining us for these sets of hearings. Obviously, it is our pleasure to have you back.
With that, let's continue on with the introductions.
MR. LAREAU: I am David Lareau, the chief operating officer of Medicomp Systems.
DR. NELSON: I am Stuart Nelson. I work at the National Library of Medicine, where I direct the Medical Subject Heading Section.
MR. PRICE: I am Colin Price from the U.K. National Health Service. I work for our National Information Authority and I oversee a range of projects to do with information for personal health. That includes the maintenance of our read code terminology and our collaboration with CAP to develop SNOMED CT.
MS. BAKKEN: Suzanne Bakken, professor at Columbia University, here on behalf of the American Nurses Association.
DR. CHUTE: Chris Chute, professor and chair of medical informatics at the Mayo Clinic and I should disclose I am the ISO liaison to the SNOMED Editorial Board and an HL7 vocabulary co-chair.
DR. COHN: And we shouldn't actually worry as we do further introductions. You all do not have to recuse yourselves or express all your conflicts of interest either on panels or otherwise.
Continue.
MR. BEEBE: Michael Beebe, American Medical Association.
MR. WINE: Mark Wine(?), Department of Veterans Affairs.
MR. HALLMARK: Jeff Hallmark(?), Department of Veterans Affairs.
MR. HOFF: John Hoff(?) at ASPI.
DR. CAMPBELL: Jim Campbell, University of Nebraska Medical Center.
MR. KELLY: Bruce Kelly with the Mayo Clinic.
MS. LEON-CHISEN: Nellie Leon-Chisen, American Hospital Association.
MR. WRIGHT: Larry Wright, National Cancer Institute.
MS. HABER: Margaret Haber, National Cancer Institute.
MR. MORRIS: Richard Morris, Office of Public Health and Emergency Preparedness.
MS. PICKETT: Donna Pickett, National Center for Health Statistics, CDC.
MS. HAMBY: Pat Hamby, McKesson Corporation.
DR. BERGLUND: David Berglund, National Center for Health Statistics.
MS. ASHMAN: Diane Ashman(?), SNOMED.
MR. NEFF: John Neff, professor of pathology at the University of Tennessee, chair of the SNOMED Authority.
MR. SCOTT: John Scott with the College of American Pathologists.
MR. BON GIORNO: Phil Bon Giorno with the College of American Pathologists.
MR. WILDER: Tom Wilder(?) with the American Association of Health Plans.
MS. FREYBURG: Elizabeth Freyburg(?), health care consultant.
MS. BICKFORD: Carol Bickford, American Nurses Association.
MR. DOWNS: Steve Downs, Robert Wood Johnson Foundation.
DR. ELKIN: Peter Elkin, associate professor of medicine and medical informatics at the Mayo Clinic and also chair of the ASTME-3101 Committee on Healthcare Terminologies and one of the co-chairs of the Templates Group in HL7.
MR. LINCOLN: Mike Lincoln, Department of Veterans Affairs and University of Utah.
MR. BROWN: Steve Brown, Department of Veterans Affairs and Vanderbilt University.
MS. CLAWES: Linda Clawes(?), American Health Information Management Association.
DR. SPACKMAN: Kent Spackman, Oregon Health and Science University and SNOMED.
DR. COHN: Now, before I turn the microphone and gavel over to Jeff, in the interest of full disclosure, even though I don't think I have anything that I need to recuse myself about, you all need to be aware I do work for Kaiser Permanente and we have a long history of core development and actually are implementing SNOMED within our clinical information systems currently. So, just so that everyone knows.
With that, I have actually -- Jeff, if you would like to give some opening comments, but I think Jeff really is the one who needs to be leading this session this morning and this afternoon.
I would just sort of alert everyone that I think it is already evident that we are going to have a time management issue, not that people are going to get less than their expected time, but we do have a lot of testifiers today. So, we are going to be sort of indicating to you as the amount of time you have for testimony is beginning to wane.
Jeff.
MR. BLAIR: Thank you, Simon.
First of all, I want to thank all of the testifiers who have agreed to come and help the NCVHS make sure that we get the right start on the process follow-up going through, hopefully, being able to identify and select PMRI terminologies and make those recommendations to HHS. Let me also restate what Simon has said that we wish we really could give all of you more time, but we do have a time constraint to ten minutes apiece.
In order to try to enable us to stay focused, we believe that all of you have received a set of questions so that we are focusing on two major issues. One is to give us feedback on the scope from a graphic that was in the questions and to see if we have the right scope, whether we ought to carve it into several different areas or whether it is too large or too small.
The other area is whether the criteria for selection is appropriate, pragmatic, realistic, complete, too much, whatever. The only other thing that I would mention before you start is that both the scope and the criteria for selection are derivatives from the report that the NCVHS presented to the Secretary in July of 2000. That report if those of you who have not had a chance to look through it yet and it is available on the NCVHS web site -- that report set forth basically the priorities that we have as we go forward with PMRI standard recommendations, a framework. It set forth a set of ten recommendations so the selection of standards is only really three of the ten recommendations.
Other things get to do with trying to accelerate the development of PMRI standards. Last, but not least, it set forth the guiding principles for the selection in general terms. Now we have to see how they might apply to PMRI terminology.
We did in February, for those folks who might not be familiar with it -- in February of this year, this subcommittee and the NCVHS, did use those guiding principles from July of 2000 and applied them to the selection of PMRI message format standards and those recommendations were set forth February 27th.
At that point, I think -- I think that is all the background that we need. Welcome, everybody. We really look forward to your guidance. I believe our first person who is going to testify is going to be Chris Chute, unless by any chance, you would rather go in a different sequence.
DR. CHUTE: Thank you very much, both of you. It is a privilege to be here. I am Chris Chute from the Mayo Clinic.
Just to review, I have already made some of these disclosures, but I also participated in one of the ANSI HISB framework documents, along with our chairman, and many others in this room in terms of collaborating and creating some of this original information.
I want to applaud what has been done so far in terms of these preliminary criteria and acknowledge that you have created multi-purpose roles and recognition. For terminologies you have outlined very reasonable starting domains and have faithfully collated what is widely acknowledged as the common criteria. What I would like to do with my time is to very, very briefly review some of the motivational issues associated with the development of terminology in patient medical records to support some recommendations I have for augmenting your criteria and scope.
We all know that one of the major purposes of a terminology is to capture symptoms, findings, events and interventions with sufficient detail and specificity to enable their use and decision support, information retrieval, recognition and, if you will, the usual applications that we are all very familiar with. It is important to keep that in mind to understand that these use cases have to be separated from their format and structure.
It is also important to keep in mind that in parallel with these detailed specific nomenclatures that we might accommodate in patient medical records, the needs for aggregating this information characteristically by way of high level classifications will persist into the future and, thus, we have to enable the accurate and reproducible grouping of this information for a variety of purposes that includes but is not limited to fiscal reimbursement management types of activities, obviously, public health and surveillance and statistical kinds of issues.
Thus, we can imagine this continuum from detailed specific representations of patient information through various and increasing levels of aggregation or grouping so that we can, if we choose, cluster like conditions of events into small groupings or accommodate very broad groups of related concerns in the context of these higher level classifications or aggregations.
Now, that view and those use cases have implications on the notion of, first, grouping an organization. I will choose to review the historical model that many of us have shared over time of this continuum of terminology from a detailed nomenclature to a classification and propose that we might rethink that notion in a more broadly-based context, the old one size does not fit all kind of approach.
Historically -- and this goes back to work in some of the national terminology symposia that we had in 1996 and later -- the idea that an underlying nomenclature could on the one hand have detailed specific patient information and then extend along a common continuum to these higher level classifications or groups was perceived to be a fairly linear, uniform and single dimensional problem and the examples were the detailed clinical nomenclatures that are evolving, the intermediate classification of ICD and its relatives and then the higher level groupings of the DRGs.
What I would propose is that we actually confront a use case that is slightly more complex, where we have needs in decision support and error detection, needs in public health and surveillance, needs in reimbursement and management and needs in outcome and epidemiology. And if we regard this field of findings, events and interventions as an instance of a patient record, it is probable and plausible that we would choose to reaggregate this example patient in a variety of different contexts, using a variety of different rules to achieve classification contexts that are not identical.
It is improbable that a single classification or a single set of rule bases could realistically accommodate the spectrum of use cases that we encounter in classification. Thus, it is plausible to imagine rules that would enable us to have a cascading set of groups or criteria and this red example for decision support and error detection of different sizes, where we have small boxes nested within larger boxes representing algorithmically or symbolically this notion of varying levels of aggregation within a common rule base.
Furthermore, these use cases that I have outlined and their spectrum of context have implications for the criteria we would use for either specifying or developing terminologies internationally and I can simplistically accommodate those into two notions of description logics, which have not previously appeared in the characterization and criteria that we have used to evaluate terminology and what I choose to call their sibling aggregation logics. By "aggregation logics," I mean the old rule-based mechanisms by which clinical events can be intelligently aggregated into higher level classifications.
These are concepts that Kent Spackman and others have talked about in considerable length in many of their publications and comments. I would assert that these aggregation logics properly should be published as a component of their attached classifications; that is to say, if, for example, ICD-9 or ICD-10-CM were to be the acknowledged and likely content for either public health and/or reimbursement criteria, then the rules and logic by which specific detailed clinical observations, events and interventions can be aggregated into these higher level ICD rubrics would be a component of a published ICD content, not a characteristic of a mapping element associated with an underlying terminology.
I will -- this is my second to the last slide -- conclude that no matter what the heck we do, we will confront significant challenges and problems, not the least of which is the human interface problem, how human beings, how physicians, how doctors, nurses and other health providers actually interact with the terminology remains a considerable challenge and burden, particularly in the face of time costs and the existing provider burden in the existing healthcare world today.
Similarly, the impact on vendors developing health information systems is likely to be considerable as they confront the challenge of incorporating what will no doubt be relatively complex and sophisticated representations of patient information into their underlying products.
Finally, we confront nationally and internationally the question of to select from what is available today or to support the development of that which should be along the lines of content, authoring environments and I would assert these newly described aggregation and description logics as components of the underlying problem.
My conclusion is to, again, reiterate my kudos for the efforts and summaries that have been done so far. I endorse them and think they are superb starting points for consideration of these problems. I would add that we might consider an additional criteria about the organization of terms in the context of their various aggregation levels and these families of associated classifications for purpose and their associated logics and, furthermore, to incorporate as a criteria for consideration of well-formed terminologies their behavior and opportunity to participate in description logics as definitions of their underlying content, as well as supporting aggregation logics that would enable their higher level aggregation into appropriate classifications and groups among the discriminating criteria we would consider for terminology.
Thank you very much.
MR. BLAIR: Thank you, Dr. Chute.
Suzanne, are you ready?
MS. BAKKEN: I would like to thank the chairman and the subcommittee members for this opportunity to provide a few remarks. I am Suzanne Bakken, professor of nursing and medical informatics at Columbia University and today I am here speaking on behalf of the American Nurses Association, the only full service association representing all registered nurses in the nation.
I am going to be very specific in regards to the questions that you have asked us to address. I have provided a fuller written statement and I would like to just point out a couple of the major points that have been provided that have been provided in that written statement.
First, in regards to the committee's question about whether or not there needed to be new groups or subsets in the graphic you provided, In looking at this particular diagram, I see terminologies, some of which were categorized by domain, for example, the nursing codes, some which were summarized in some ways by purpose, for example, having SNOMED CT classified as a convergent terminology and, thirdly, some terminologies, which were classified by the area of the healthcare process that they cover; for instance, things that are specifically listed because they contain diagnoses, interventions or outcomes.
One of the other issues in terms of looking at the particular diagram is I think there needs to be some additional clarity to the notion of clinically specific and convergent as subset labels. By looking at the content within those labels, I believe it implied that those two categories of terminologies are concept oriented terminologies, but that needs to be slightly clearer.
Another potential issue is the fact that physician diagnosis and intervention codes are categorized as diagnosis and procedure codes; whereas, the nursing diagnoses and interventions are categorized as nursing. So, two particular recommendations that we have in this area is maybe to consider the use of intervention, rather than procedure as a label and I think it may be necessary to categorize terminologies by multiple dimensions that may take into account their domain coverage, their primary purpose and some of the underlying semantic structure of the particular terminologies.
Another question you asked us to address was whether or not we should add or delete the terminologies in the list. I have provided in the written statement a list of data nursing codes and one other correction to the table will just be that the Omaha System and Perioperative Nursing Data Set were incorrectly labeled as not in the UMLS, which, in fact they are included in that.
So, the recommendations that we have in this particular area is that if you are going to consider data sets as included in PMRI terminologies and I see Deeds(?) listed, you may consider the addition of the Nursing Minimum Data Set to the list.
The second thing to consider and I think requires the evaluation is whether or not it would be appropriate to include the International Classification of Nursing Practice in the list. It is an international product. However, it has been recognized by the American Nurses Association and we have no recommendations for deletions to the list at this point in time.
You also asked us to address the list of priorities. The things that we consider particularly high priorities were the issues of pharmacy and laboratory and also the diagnoses, intervention and outcome codes from the variety of clinical professionals, including physicians and nurses. The context is our rationale for this; issues of patient safety, health care quality, multidisciplinary care and communication.
At this point in time, we have no suggestions for designations on the list that we would consider from our perspective a low priority.
In terms of the criteria, one area we would like to see in addition is that you include the notion of the documentation of reliability, validity and clinical utility. A number of the terminologies on your list have included that in their publications about their terminologies.
In terms of modifications, you asked us to comment on whether or not the criteria should vary according to the type of terminology. As I look at the list and the type of -- and the definitions that you provided, you included terminologies that could be considered data sets, classifications, nomenclatures, et cetera.
In the early days of the ANA's Database Steering Committee, we proposed a single set of criteria to look at terminologies and then in the late nineties -- it sounds like so long ago -- we found that our criteria were not sufficient to recognize the types of terminology products that were being submitted to us because of the changes in terminological science and the type of supporting tools for that science.
So, I have provided for you in Table 2 in the written document an example, our criteria and which are the criteria, which we apply generally to all terminological products submitted to us and then those, which we specifically only apply to things, which are classifications or concept-oriented terminologies. So, we believe it is important that you need to clarify which criteria particularly relate to which type of semantic structure, particularly in relationship to the notion of clinically specific terminologies, which seems to imply that these are concept-oriented terminologies versus another type of terminology.
I would like to support in particular one of the major points that Chris Chute made, which is the notions of the relationships among terminologies. I think it is important to clarify which are terminology characteristics or abilities versus which of the types of roles or abilities you were talking about are potentially provided by models or supporting software for a terminology.
An example of this area, where we have spent work on nursing in the last several years is the notion of developing not a reference terminology for nursing, but a reference terminology model for nursing. We have a committee draft shortly moving towards a draft international standard within the International Standards Organization at this point in time. Also, to support Chris's point about the terminology software tools and rules engines and so at that particular point, we are meeting perhaps less eloquently the notion of both the things that support the description logic, the very finely detailed clinical specification and rules engines that would support classifications from that.
In terms of whether or not PMRI terminology developers should be ANSI accredited, our opinion is that there should be no requirement for the terminology developer to in itself be ANSI accredited. We believe it is important that developers affiliated with an ANSI-accredited organization, that there are open meetings with timely notification, that the balloting process is published and that it accommodates public commented appeal and, very importantly, where existing standards are present for definitions, processes, et cetera, they should be used.
So, in conclusion, we very much support the notion of a national health information structure that -- and we believe it is critical for ensuring patient and public safety, as well as improving the quality of health care. You face an important decision because PMRI terminologies that facilitate data sharing and reuse are an essential building block of such an infrastructure. However, to achieve that optimal impact, the PMRI terminologies must be inclusive of the disciplines that contribute to health care processes and outcomes.
Thank you.
MR. BLAIR: Thank you very much.
While our next speaker is coming up, I really should have recognized Suzie Beebe for helping set up this session and making sure that all of you were invited and got the information that you need. Thank you, Suzie.
MS. BEEBE: Thanks, Jeff.
MR. BLAIR: Our next -- Dr. Colin Price, thank you for coming all the way from England to be with us.
MR. PRICE: I just really briefly want to share with you some of the NHS's extensive experience in three main areas, basically to run through the history of what we have done over the last ten to fifteen years; secondly, to make suggestions for your classification of terminologies that fits more with our view of the world and, lastly, to pick up on two aspects of your criteria for selection, the properties and some of the underlying business aspects.
The development history, just to underpin that by telling you that the NHS is a very diverse and currently unstable environment. We have a general election in three to four years. There is a huge government commitment to NHS information technology. There are some aggressive targets coming up in about three years time and to achieve these, we are taking much more centralist control of implementation, ruthlessly applying standards and taking a much more controlled approach to industry procurement.
In terms of terminology development, in the 1980s, within primary care in the NHS, a number of commercial schemes appeared. In 1988, the clinical professions endorsed the read codes. Following that, in 1990, the NHS purchased the read codes and from 1992 to 1995 enhanced them in a large scope project to produce clinical terms, Version 3. This did not do well in terms of implementation and there were a number of public inquiries into the read codes, which lead in 1988 to a review of our NHS terminology options and in 1999, as a result of that, we agreed with CAP to develop SNOMED CT and 2002 has seen the first release of CT and we are now investing heavily in our evaluation and implementation foundation programs.
Just to share with you the outcome of our review of terminology options, there are five options considered. Firstly, don't use a standard terminology, which was seen as a recipe for anarchy. Secondly, continue to use the read codes. That was rejected because of brund(?) damage and the cost of maintaining independently.
Option 3 was simply to use something like SNOMED, borrowing it off the shelf. Option 4 was to collaborate with SNOMED. So, we had some control. And Option 5 was to collaborate with someone else. That was rejected as there wasn't seen to be any other suitable player.
Option 4 was selected. This set of options was being reviewed in the last 18 months and continues to be regarded as valid within the NHS.
So, moving on to our goals, I mean we want to roll out a terminology nationally for multi-purpose use across a range of professions, in a range of environments and we want it to be extensible for patient access and to social care. We have two strategic targets that indicate that in April next year, we will begin to roll out SNOMED CT nationally.
Coming on to the second bit of our experience, which is the way that we might classify terminologies, this is a familiar set of functional requirements that really picks up on what Chris Chute said and there is a continuum here really from direct patient care purposes to indirect with a cutoff maybe about there.
If we plot this on a matrix with functions from direct to indirect along the bottom and content from focused comprehensive along the vertical axis and then something like SNOMED CT will sit up there and CTV3, which is now completely incorporated into SNOMED will sit there and other things like the first version of the read codes designed for primary care, things like the International Classification in Primary Care, maybe LOINC will sit there.
Over towards the right, CPT4 and ICD-10 there maybe DSM-4. I mean, you may argue about the precise positions here, but in essence the NHS sees as using a comprehensive terminology and mapping it to formal classifications. Another thing to say is that things like SNOMED CT through their reference properties begin to pick up more of the indirect care functions and, as I say, the NHS picture is that we will produce a mapping to the classifications that we will continue to use.
So, I think one question for you maybe is to do with whether a comprehensive or multiple interoperable schemes are ideal and for comprehensive, there are issues around the advantages of the single provider organization, the fact that interoperability is inherent, supports uniformity of code structures, which is attractive to the vendor community and huge economies of scale in support, education, maintenance and the development of cross maps.
Against all this, the monopoly concern may be too big organizationally to respond to changing requirements, maybe too large structurally, needing subsets, may constrain specialist requirements by imposing a uniform structure and it might be difficult to get a wide editorial input. So, the arguments for interoperability, schemes that might be closer to use for purposes and expertise often strongly owned by the professional groups who develop them. Maybe they are already and rapidly adoptable stage, maybe more responsive to change requests and against them.
These don't seem to be numerically large, but actually the financial overheads in maintaining interoperability between a large number of schemes is huge. We must invest about $150,000 a year just maintaining interoperability between three versions of the read codes for the NHS.
The other thing is the tendency for scope creep of these schemes and a good example might be that LOINC has moved from LUD(?) LOINC to clinical LOINC and begins to pick up some of the contents of other schemes.
Just to quickly show you this slide, which came out of a survey we did this year and to pick on two points, that 50 percent of terminology experts believe within ten years, we will be seeing multiple interoperable schemes; 25 percent believe in ten years, we will be seeing a single global scheme.
So, on to criteria for selection. Well, in terms of technical properties, I actually think at this stage, these are mostly not normally controversial. There are some well-rehearsed desiderata backed up by academic and standards work. I have to say that quite a lot of the advanced technical features appear to end users to be fairly superfluous for the immediate short term and medium term requirements.
So, I am not going to dwell anymore on the technical properties, but I do want to pick up on some of the business aspects. The first is to do with supply and demand for terminology. The second is to do with financial structures and the third is to do with long term provider. These were important considerations in our developments and review of the NHS's business case for investment in terminology.
Again, just to go back to that little bit of research and to point out the red arrows, which suggest that in a semantic differential questionnaire, an open source type business model, phase roll out were important, national coordination of terminology efforts and central mentation, which is relatively easy for us to do in the NHS. We also regard it as very important for success.
Supply and demand then, actually when we talk to NHS end users, there is very little real demand for terminology. They think it is a good idea. They are not sure they want to give up other things to invest heavily in it. And there seem to be a limited number of commercial suppliers of large comprehensive schemes. There is also a lack of clarity about scope, purpose and benefits and the perception is that the benefits from adopting a terminology at national will be governmental and central rather than flow to individual uses.
There is a feeling that a commercially aggressive business model will be non-viable. For intellectual and property terminologies is only valuable if people are willing to pay for it. So, in terms of financial structuring, I think your general criteria that you submitted in your list are mutually exclusive. Timeliness, dynamism and flexibility just don't come cheap and, you know, we need to recognize that fact. Any new endeavor probably needs 20 to 30 million dollars of capital to start it off. That is based on our experience of developing version 3 of the read codes and our investment into SNOMED.
You need to guarantee an income stream, which needs to be hard money and if you were to look at a global scheme, I think our current projections is that you would need around $l5 million annually to maintain a global comprehensive terminology.
MR. BLAIR: I want to make sure I heard you correctly. Did you say 15?
MR. PRICE: Yes. This probably cannot be sustainable as an aggressively commercial venture.
The last point that we consider is long-term viability of provider, wanting to know that switching costs for terminology are potentially very high in terms of migrating of databases, reporting the arrangements and protocols. Any low viability model is a high risk. Open model with subscriptions, supports at national level with a core product and extensions and subsets seems to offer the best advantages.
So, in summary, since 1992, the NHS has remained committed to using a single comprehensive scheme and we remain committed to SNOMED CT and we are investing 3 millions of dollars worth of investment this year to lay the foundations for implementation of the NHS. We believe that the provision of extension subset mapping mechanisms addresses many of the counter arguments to comprehensive schemes. A global business model needs to be open, contributory and non-predatory and underpinned by central government support and we need to recognize that terminology isn't an end in itself, but needs to be seen to be adding value to something else.
Thank you.
MR. BLAIR: I think our next speaker is Stuart Nelson.
DR. NELSON: In the ten minutes of fame allotted to me by the committee, I wanted to address several aspects of the questions that were sent to us. For the most part, I agree with Chris that this has really been a very noble effort and a very good effort. I think there are some areas that need strengthening and then there is one area that surprise -- it is not surprising that both Chris and Sue have already addressed it, but I will go through it as well.
So, I am going to address a number of these different areas very quickly. The terminologies organizations, atomic concepts, relationships, priorities, the maintenance process and pricing.
Chris described a continuum of information terminologies, ranging from the high level aggregation of information and groupings for reimbursement down to the patient level. I suspect that there is a level that is below the clinical level as well that we have to be concerned about, particularly with the advent of the increased information that we are seeing in genetics that will come to play. I am not sure that we have to talk about all of these different levels as being a continuum so much as we need to recognize that there are at least some very distinct types of uses that the terminology goes through.
Much the way the others, I think that the best way to organize your consideration of terminologies is to look at it both in terms of the level of discourse, as well as the areas to be covered. I am going to address this problem, this notion of an atomic concept and what I want to first point out here is that the level of discourse is going to determine atomicity and it determines the granularity of your discussion.
This is a perhaps little bit more subtle point than we want to discuss at a meeting like this, but I think it is some things that we need to bear in mind when we look at these things. Here was my suggestions about the areas of coverage in terminologies that we should consider and I agree with Sue that we shouldn't split it out according to which profession is doing it. I did call them procedures and not interventions, but I think that all of those things are different areas that we could look at as coverage.
As far as additions of vocabularies are concerned, I think there are quite a few that need to be put onto that list. The RxNorm project I have been working on and I think this committee has already been briefed on that by Betsy Humphreys; MediSpan and Micromdex are also pharmacy knowledge-based vendors that provide terminology information, although my impression is that all of the pharmacy knowledge-based vendors would like to get out of the terminology business because it is a loss leader for them.
I did not see on the list the International Classification of Diseases for Oncology or the International Classification of Primary Care. There are some new efforts by the dermatologists to organize their patient observations. We did not have listed originally a need for taxonomy of organisms or a taxonomy of anatomy and I think that those are both good efforts in those areas as well.
I did want to point out that there is that one of the vocabularies has changed its name. It is now the International Classification of Functional Disabilities and something.
So, what is the atomic concept? Well, that is a good question because an atomic concept is something that is at the level of your discourse, but if your level of discourse is changing all the time, what is the atomic concept? You know, I am not going to start talking about how I came over here today by talking about how you make steel for the rails of the Metro.
You can describe things at any level of detail that you like. So, to me, if you are going to -- you can describe things to a very fine detail and still not completely define it. So, an atomic concept, I think, in that sense is a myth. What you have to say is what is the level of discourse at which I am expressing something and is it a precoordinated expression or a postcoordinated expression?
I think what you are trying to say there is that you want to have a postcoordinated expression for anything that is at a greater level of detail than your level of discourse. Another great myth, that there is such a thing as a concept. I am not going to go into that one. It is a deep philosophical argument, but essentially what we do in terminology is we do something that is philosophically impossible but by engineering we can do it.
There is a great human tolerance for ambiguity in terminology. Computer systems don't deal with that very well. We need to recognize where we are. Zipf's Law has a lot to do with the whole thing of -- the whole problem of this atomicity and that is Zipf's Law is a lot of linguistics. It says the things that you talk about frequently get shorter and shorter names, become atoms. So that at the level of CMS, they are going to talk about things with short names that we are not going to talk about on a clinical level.
Relationships with other terminologies, I think Chris described this very well with his comments about descriptive and aggregative logics. Many of the terminology systems that we currently see have sets of rules that are human understandable, but are not expressed in any way that they are computational. This is a major difficulty, I think, for developers.
We also need to look at those kinds of systems and make sure that they are not any terminology system and make sure that it is not vulnerable to gaming. Part of this is the idea that terminologies have to have what I call representational integrity, which means that you can say something in one and only one way. If I can code what I am doing to a patient in three different ways and one way makes me $1,500 and another makes me 500, which am I going to use?
That is what we call obfuscation for remuneration. The other thing is that you have to be very careful when you consider reference terminologies about whether or not -- how aware they are of the implications of changes in the reference terminology to the other terminologies that are referring to them and how those changes are propagated.
System dependencies: My experience over the past six years working with an operating system has taught me that although a nice first order approximation, you can talk about terminology being independent of the system and of the interface. In the long run it is not. For example, you need to deal with the problem of character sets. What character set are you proposing that we use?
When are we going to draw the line? Where are you going to draw the line? Most computer systems reserve certain types of special characters for the operation of the system. How are you going to ensure that that is not going to be something that a character that you would otherwise want to use?
I think when it comes to that, if you are talking about using terminologies with multiple vendors, then there is going to have to be some set of open standards about exactly what the terminology will and will not do and what the systems are and are not allowed to do in order to deal with that problem.
Priorities: I think for me as I look at it, I am not in the practice of medicine anymore, but I do read a fair amount and I think the biggest priority right now is patient safety and I think the argument that if you could just get physicians to enter orders, I think the data suggests that you could reduce errors, at least in medications, by 50 percent with computerized physician ordered entry. So, I would say that is a pretty high priority.
Next, I think, on our priorities is to get down into a problem list and describing procedures and interventions on a successful array, much lower, I think because I think there are other problems that haven't been solved yet, is the idea of achieving a full description of a patient.
Maintenance: Maintenance, obviously, has to be responsive to user needs and it has to be quick. It has to be very timely. Only if it is timely will it reduce the local update penalty, where somebody has to add a new term and then when the term is changed, they have to go back -- when a new term is added to the vocabulary, they have to go back and modify that.
This seems to be a little anti-democratic, but I don't think that it is possible to do vocabulary development on a consensus basis. I think what you do is you pick the quintessential middle child, who listens to everybody, understands the engineering about what has to be done and let them struggle it out. It is not going to be perfect. None of these systems can be perfect, but if you let somebody responsible take -- do that job and respond to what the users are, then I think you can judge whether or not they are doing a good job.
I think you do need to have a real open setup for an organized review process, where input is obtained from all the interested parties.
Affordability: We have an economist sitting here on the panel. So, I am not going to try to teach economics, but when I learned microeconomic theory, I was taught that in the competitive environment price was marginal cost. What is the marginal cost of providing terminology for one more provider? It is not very high. However, I don't think any of the providers would be too happy with pop-up ads in the middle of their patient care environment.
There are two other ways you can look at how to price something. One of them is based on what the value added to the system is by the terminology, which might be a hard thing to measure. And the other is to look at what the alternative costs are in terms of -- you know, if you are asking a certain price for a vocabulary, what is the alternative cost? What would it cost somebody else to do it?
That is another fair way of determining what the price is. With that, I am going to say thank you.
MR. BLAIR: David Lareau.
MR. LAREAU: Thank you, Jeff.
Good morning, Mr. Chairman and members of the subcommittee. I am Dave Lareau, the chief operating officer of Medicomp Systems. My comments here are going to be very specifically directed to our own experience. For the past 24 years, we have been developing tools for clinical decision support and documentation at the point of care. The biggest challenge for us has been what Chris called in his testimony the human interface challenge.
In working with clinicians over this period, we have been challenged to make something actionable at the point of care during the clinician/patient encounter. A major part of that challenge was how to accommodate the clinician's thought process without interfering in it or changing it so they became a data or terminology collector, rather than a practicing clinician.
What we found is that clinicians process, what we call clinical concept versus individual or atomic terms and the relationships between them in order to arrive at a diagnosis and what Suzanne calls an intervention of some sort. To illustrate the importance of that concept because it is going to -- all of my responses to the specific questions come directly from this experience. They are very biased. They are very experiential and the way I am going to answer them is reflected by the way we process concepts.
To illustrate this importance, consider the example of a patient with chest pain radiating to the left arm, as opposed to chest pain radiating to the back. In the case of chest pain radiating to the left arm reported by a patient or discovered by a provider at the point of care -- and that is what I am talking about -- the clinician might reasonably suspect the diagnosis of angina and absent other findings, order an electrocardiogram or cardiac stress test. Even though it is terminologically quite similar in that many of the same words are used, the concept of chest pain radiating to the back, as opposed to the left arm, might reasonably lead a clinician to suspect a diagnosis of aortic dissection.
In this case, further questions about recent trauma or an order for imaging studies might be appropriate, but a cardiac stress test would definitely not be an appropriate intervention at that point. To further illustrate this concept and belabor it a little bit, the importance of fully-expressed clinical concepts consider neck pain radiating to the left arm. Again, although many of the same terms are used and even some of the same secondary concepts, neck pain radiating to the left arm might indicate a nerve problem originating in the neck for which cervical spine imaging studies might be appropriate.
Two of these examples I have given include the concept of radiating chest pain and two include the concept of pain radiating to the left arm, but all three indicate very different medical problems and require a fully expressed concept in order to be actionable by the clinician at the point of care.
To enable efficient point of care use of these concepts, we found it necessary to organize them in a hierarchical structure. This hierarchy of precoordinated concepts enables assignment of predictable properties to each concept, such as its relevance to various diagnoses. In the previous example of chest pain radiating to the back, this concept has higher relevance to aortic dissection than does chest pain radiating to the left arm, although both inherit the properties of their hierarchical grandparent, which is chest pain.
This combination of fully expressed clinical concepts and predictable properties for use by software applications has given software developers the means to build applications for clinical documentation and decision support, which are usable and actionable at the point of care.
The balance of our testimony and my response to the specific questions will reflect greatly the bias of this experience in dealing with terminology use at the point of care. We recognize that more granular terminologies are more appropriate for other uses, like research, and further acknowledge that mapping between terminologies must be a priority for all terminology standards developers.
We suggest the subcommittee give careful consideration to accommodating the terminology needs of healthcare providers at the point of care. In terms of the organization of the subsets of PMRI terminologies in the advanced material, this can be reflected by either establishing an additional subset for point-of-care terminologies or human interface terminologies, as Chris referred to them, or in a somewhat more radical change, including point-of-care terminologies as a separate type of convergence terminology.
Our belief is that the information from the encounter has to converge at the data storage layer, but it also has to converge to the point of care for action. The value of a very granular atomic convergence terminology for research outcome studies and other analyses is clear to us. Over time, use of this data will provide valuable information to monitor population health and should lead to improved outcomes.
However, even in a large population, outcomes are improved one patient at a time, a process in which the patient/clinician encounter is a primary component. At the moment of that encounter, information must converge in a way that is actionable during the encounter and does not unduly interfere with the clinical thought process or lead to decreases in clinician productivity.
In defining the scope of PMRI terminologies, it is also important to consider the role of the patient. As the use of the Internet expands, patients will be increasingly involved in the management of their own health care. We see this in the vendor base of our licensees.
We believe terminology standards must allow for appropriate levels of participation by patients, as well as clinicians, which further complicates the human interface problem. In terms of priorities for the selection process, since we live in the real world of rolling this out and vendors and hospitals and large health infrastructures, it is our belief that existing investments in billing, laboratory and pharmacy systems total in the billions of dollars for equipment, software, training processes already in place and much of the healthcare reimbursement structure is based on the use of diagnosis, procedure, drug and laboratory codes.
The effect of any change in terminology requirements for these systems may be significant and could require extensive modifications to existing applications and reimbursement criteria. Payers, providers, healthcare enterprises and application developers must be given sufficient lead time to implement any changes, which must be forthcoming.
From Medicomp's perspective, highest priority should be given to terminologies directly affecting current, widely implemented processes in order to avoid push back from the vendors who are out in the hospitals and the providers' offices and the payer systems. In decreasing order of priority, these are diagnosis and procedure codes, drug codes and laboratory codes.
Message-specific codes are also important. Developers need to have a firm understanding of how their systems will be required to communicate within the national health information infrastructure and have sufficient lead time to implement the new standards. The lowest priorities in our view will be convergence and point-of-care terminologies. These are not as widely implemented now nor are they as critical to existing processes. They are critical for the things people are talking about, such as patient safety, drugs, laboratory orders, but the processes are not currently in place to do that.
The processes in place for reimbursement, billing, et cetera, are in place and these people need sufficient lead time. Also, it may be premature to select convergent standards without having in place the points from which they converge.
The criteria for terminologies seem to us comprehensive and appropriate. Our only comment regarding modification of the criteria is to consider terminologies may require fully expressed combinatorial clinical concepts in order to be actionable at the point of care and should not be limited to purely atomic terms.
It is our opinion that the balloting process required of ANSI standard developers and the consensus process could inhibit the ability to distribute terminology updates to end users in a timely fashion and should not be an absolute requirement. Terminology developers, however, should be encouraged to maintain a practice of timely and public notification of standards development meetings.
We agree with Suzanne Bakken's statement that they should probably be affiliated with an ANSI standard group, such as HL7. We believe it is important that all the terminology standards developers be expected to actively participate in mapping efforts and to provide tools to other terminology developers for cross mapping.
In closing, I would like to thank you for having us here and I think the work you have done so far is just amazing.
MR. BLAIR: We are about to head into our questions. There is one other person that deserves recognition and that is Steve Steindel. He was very helpful in helping us refine and add to both the scope and the criteria for selection. So, I wanted to thank him at this time.
Simon, would you mind leading the questions.
DR. COHN: Sure. Actually, I have a couple. Maybe I will start with a question or two and then leave it to the other subcommittee members.
Actually, I also want to send regrets from actually Kepa Zubeldia, who is also a subcommittee member, who was unable to be here today. We expect actually Dr. McDonald to be here, hopefully, by later on this morning. I think as you all notice the weather has not been very positive here this morning and I think he found some difficulty getting out of Indianapolis for the first flight of the morning. But, hopefully, he will be here by noon.
Now, first of all, I want to thank all the testifiers. I think there has been a fascinating set of discussions and, obviously, we will be having more. It actually reminds me of a lot of thoughts I have had over the last ten years, some of which I haven't thought about for awhile.
Colin, first of all, I wanted -- I was very interested in your presentation. I guess I am hoping, first of all, that we have an electronic version of this since a number of the things got cut off in the formatting process. Can you talk a little more about -- you had a slide that you went through very rapidly about predictions for the next five to ten years, which unfortunately didn't show up well in what we received.
But I was actually just wanted to make sure that I understood what this reflected. Can you just sort of maybe explain to us a little bit about -- it seems to me that there is -- at least you did some sort of a survey and there seemed to be an opinion that we were all going to wind up in incompatible, non-interoperable systems in the next five to ten years. Was that your conclusion on this one?
MR. PRICE: Let me --
DR. COHN: I presume this is from experts that you actually --
MR. PRICE: Firstly, yes, you do have electronic copies of these slides. I need to reference my electronic copy to be able to --
DR. COHN: I apologize.
MR. PRICE: -- just look at the figures here, which I will do now.
This was a survey undertaken last spring, which some of you may have participated in, which involved, in fact, 123 terminology experts worldwide responded. The question asked specifically was in your opinion in five and ten years time, what would be the global picture of terminology deployment in advanced health economies, such as the U.S. or the European Community.
They were given the five options of multiple and compatible schemes, multiple, interoperable, a single global scheme, something else and don't know. The response was that in five years time, over 50 percent, we would still have a picture of multiple and impossible schemes. In ten years time over 50 percent, we would have multiple schemes that were interoperable and 25 percent believe that in ten years time we would have a single global scheme.
DR. COHN: Okay. Is there any -- I guess I am trying to think in my own mind, there is obviously the issue of global and then there is the issue of within any of our national units at U.K. or the U.S. or whatever. Were there any comments made about that at all?
MR. PRICE: There were a number of comments. I mean, I am happy to make available to you the raw data from all of this. It is actually on the Internet and I can make it --
DR. COHN: I think it would be useful to see what the expectation is.
Now, let me also just follow up with a slightly different question, probably from you and also David and the others may want to comment. I was reminded in the presentation that -- and this is something I think that Dr. Chute and I discussed probably a number of years ago, about the issue of business case and that fundamental to any progress moving forward in this whole area is a view of importance, business case that people can clearly understand and that makes sense.
Now, obviously, Colin, I know you have been working in this for 12 years that I know of and I am sure longer than that that I don't know of. You have tried to move up this mountain a number of times. Your comment, obviously, was is that the perception of business case seems to be just central, that the business case is perceived as it is good for the government and everybody else doesn't -- I mean, once again, I am putting words in your mouth, but the sense I got from your discussion was is that the perception in the U.K. is is that the business case is primarily to help the -- help your government administer the health care system and it may not have quite as much value to the individual practitioner.
Whereas, we heard from David that his view was, gee, that the business case on these things needed to be to help the physician at the point of care do a better job at point of care. I may be, once again, putting words into your mouth. Can you help or can you all help us sort of figure out where -- what you think the business case around this really is?
MR. PRICE: Let me tell you about -- clearly, in the last ten years, the NHS has invested tens of millions of dollars in its terminology efforts and for probative reasons, we have to have business cases, which are put together on very structured and formal grounds, including strategic, economic, commercial, financial and project management cases. When we do business cases for central projects, such as terminology development.
I think I am talking tomorrow and I will be telling you about the local implementation strategies that also have to have local business cases. So, we combine the central initiatives that have the structured business cases I have described with a range of local implementation initiatives that also produce their own business case that is tailored to local requirements.
MR. LAREAU: I would also like to add to that. It is an unfortunate fact that the publication of the 1997 Evaluation and Management Physical Exam Guidelines led to a massive increase in interest in what we do on the terms of the providers because all of the sudden they could -- this was a shock to us. We couldn't stand it when those guidelines came out.
They were indecipherable by the providers, but it provided the impetus for people to look at our structured prose at the point of care and say if I follow this, I don't have to purposely down code anymore and the business case for the providers was not a clinical business case. It was a reimbursement business case. The clinical business case came into it because with the use of point-of-care tools, they could more aggressively use physician extenders, such as nurses, PAs, et cetera, at the front end of the intake process and for managing patients with a problem-oriented view of the record and actually get better information with less clinician time.
It came down to us for the individual providers, they look on additional requirements for data collection as a drain on their time and their time is the one non-renewable resource in the patient care environment. So, they are very protective of it. So, we were fortunate, unfortunately, that our stuff helped people to keep their reimbursement where they wanted it to be with the E&M guidelines, but they did not get into and they did not accept any premise that this would help them provide better clinical care going into it.
That had to be proven to them over time with some other method of payback and that is how we have managed to do that. It is a battle. They don't like change and when you hear a clinician in private practice talk about a patient chart, you still hear them saying my chart, my charts, as if that chart is not actionable or usable or belongs to a wider enterprise or even to the patient.
So, there is a tremendous cultural resistance toward that chart becoming open to anyone in requiring standardization of codes at the point of care. There is still resistance to that.
MR. AUGUSTINE: Dave, let me follow up on that.
What methods have you found to be the best? Like at my organization right now, we are implementing a pseudo EMR with electronic signature and moving things out of paper chart and electronic and getting that -- the behavioral component is the most difficult part of the change. What methods have you found to be very useful in that?
MR. LAREAU: In each enterprise, we found it necessary to define an appropriate number of clinic champions. This requires some change. It requires some investment up front on the part of the provider for training and it is such a radical change for them, they need to have peer support in that. They need to have somebody who says now look, I did this, you can do it. It was a process of defining a clinical champion and having that -- a clinic champion and having that person identify what everybody would call the low hanging fruit.
What can we do quickly to get this? It usually meant the implementation of standardized protocols for routine events that previously were done by the physician or a PA, such as doing a complete review of systems, gathering a full history, et cetera, and seeding the record in advance for the clinician. That was an early payback, but it is a battle that does not end until the final clinician is live.
MR. BLAIR: First of all, I want to thank everybody for absolutely outstanding, helpful guidance and testimony. I would like to probe just a little bit deeper on a couple of the criterias. In particular, one of the criteria is timeliness, meaning how quickly a terminology developer is able to identify new terminologies or corrections or additions or extensions to terminologies and be able to incorporate them into the terminology set and make that then available presumably electronically to the healthcare industry.
I might indicate my bias right up front, that the standards -- the experience that we have had in how long it takes to update health care information standards and terminologies up until this time may be very much inadequate if we are going to wind up having PMRI terminologies used in electronic format on a nationwide or worldwide basis. So, I would like to hear from each of you what your perception is of what would required response time for terminology developers to be able to update the terminologies and get the new terms into their terminology sets.
David, could we start with you?
MR. LAREAU: Sure. Thanks, Jeff.
We have found in the real world that we have to publish twice a year minimum a full, updated, fully quality assurance tested set of our terminology as we have rolled it out. We used to do it quarterly, but the vendors said we don't have the resources every 90 days to go to every site and educate people about what is different, what is changed, what is new. So, what we did is we went to a six month model, but we also found it necessary to reserve certain sections of our terminology that were cross linked to other terminologies that have to be updated monthly, such as terminologies.
We have further found it necessary that new terms, not the change of existing terms, the addition of synonymy, but new terms we have had to make available as a down load, controlled by the vendor at the site to download any new terms in between those six month release dates. The official release dates had to be at least twice a year. Providers were not comfortable otherwise to accommodate changes in additions to terminology. We make updates available and they can be updated on demand by any site that wants them. We had to allow for that variability by the vendors.
We couldn't say to them you have to go out every 90 days or monthly to update stuff. So, we had to do it remotely and then official release twice a year.
DR. NELSON: Can I comment?
MR. BLAIR: I would like each of you to comment, please.
DR. NELSON: Additions are easy, Jeff. Additions to vocabularies are easy. Modifications are the tough ones because modifications mean that you are -- what you modify, you have got to go back somehow and have that reflected in what your previous records were like. You have to have some sort of update model of that.
Now, for a long time, the medical subject headings has had daily additions to its indexing vocabulary. Not a problem. It is the changes that take place, the modifications that take place that take a much longer period of time.
There, once again, it is a matter of training the users and sending out all those changes to all the different places. My current model for the RxNorm project is to try to eliminate this local update penalty of having to add in a new drug is that what we would like to do is get to the point where when the FDA approves a new product, that within the week we will have it into the RxNorm form so that it would support the physician order entry.
MR. BLAIR: Do you have any sense if you were to try to quantify what you think are reasonable time frames for modification of terminologies if this were done on a national basis?
DR. NELSON: I think you would have to ask the vendors, the system developers, but I think I agree with David, it would be more in the neighborhood of six months to a year for real modifications.
MR. BLAIR: Dr. Price, what experience have you had in England with respect to --
MR. PRICE: With read codes. Four or five years ago, we used to release them every three months and we changed to doing that six monthly. In fact, that has worked very well and we have had very few issues with that. On occasions we have had to publish a specific code to our users in between releases. A good example is when unexpectedly a meningitis C vaccination campaign was introduced for undergraduate students. We had to publish a code for meningitis C vaccination between two releases.
The tricky one is our drug releases, which we do every month and I think there is a sense that that might not be frequently enough. The read code, the drug dictionary is used for electronic prescribing. Clearly, if a new drug comes onto the market between releases and we don't necessarily get advanced notice of that, then there is an issue about people not being able to prescribe it.
The other facility we provide is the ability within the structure to add local codes that can then be converted to formal read codes within the next release cycle. So, there is a mechanism whereby a local user can tide themselves over between releases if it is absolutely necessary.
MR. BLAIR: Dr. Bakken and Dr. Chute.
MS. BAKKEN: Yes. I would like to make two comments in this regard, both of which are supportive of things that have already been said. What it really depends on is the domain of content that you are talking about and how rapidly it changes and, secondly, what has been implicit in everyone's remarks is that there must be some notion of terminology services that are available between official updates, which I imagine for most types of things, other than pharmacy, would be on a quarterly or every six month type of basis, but the local users must be supported by technology-based terminology services between those times to get -- have availability to codes that they may require for the applications in the meantime.
DR. CHUTE: This is Chris, Jeff.
I honestly think it would be a disservice to give a singular answer to that question for two reasons. One, it is going to be a function of the use cases. To the extent that as in Dr. Price alluded somebody can't do something for lack of a terminology, that is one character of use cases, but at least in this country, that is at present a modestly small category of dependency, when one typically has the option of free text opt-outs or some other mechanism, local terminology additions of doing what needs to be done absent a formal update mechanism.
The second dimension of this consideration is the complexity of the notion of update in and of itself. It includes the idea of soliciting terms from the users, of reviewing them, of vetting them, of accommodating them in a probationary context, of incorporating them into a terminology, of distributing that terminology, of incorporating that distribution into systems. You can see the trend here.
It is a very, very long process and to put a singular date or time frame on any aspect of that process might actually be misleading.
DR. COHN: I actually wanted to welcome Dr. McDonald, who has just arrived. Clem, do you need to introduce yourself or recuse yourself on any issues coming before us today?
DR. MC DONALD: [Comment off microphone.]
DR. COHN: Okay. Welcome.
Mike.
DR. FITZMAURICE: Stuart mentioned some lessons from economics that he has learned and I remember some economic classes, too, where marginal cost pricing is best, but only if you cover your variable costs in the short run and the total costs in the long run. It seems to me what Dr. Price said was that it is going to take, if you start up something, $20 to $30 million to start it up, maybe $15 million a year in maintenance costs.
And I infer from the decision that the United Kingdom made in joining with SNOMED is that there may be decreasing costs; that is, the cost of supplying vocabulary to one more doctor is very small compared with, say, the first and the second and the third doctor, but you have to have a large market in order to amortize that fixed cost up at the beginning and to spread out the maintenance costs. You would think that one country would be big enough, but it may be that this is a very large thing to do.
Does it call for collective action? That is, does it call for United States Government support? It doesn't mean that the government has to do it, but the government has to support this because it has value and it has large start up costs or has the value not been proven and it is something we will just have to learn over time.
So, I would like to kind of address this to Dr. Price and also to Stuart Nelson and I would like to ask Chris if we could get a copy of your slides, too, because I thought they were outstanding as well.
So, Dr. Price, does this require collective action on the part of a government where we have not central and nationalized health system but everything is spread out. This thing, this vocabulary system, may cost so much to build to begin with, so much to maintain over time that no one segment of the market could support it.
MR. PRICE: Well, I can only really talk from the approach that the U.K. has taken and that is to recognize that the start up costs are huge. I am not sure that actually adding the additional use, it doesn't increase your marginal costs in a significant way because adding a user requires distribution, training support, educational support, health tech support. It increases a number of requests that you may have to process for modifications, in addition to the terminology.
So, I think you should not underestimate the marginal costs of bringing on new users, particularly if you are bringing on a new user group specialty. The question I would put back to you, I think, is that if you don't have a centralist, collectivist approach to managing your national terminology problem, whichever approach you appear to be adopting, manages the interoperability issues between the multiple terminologies that you have in a way that enables you to capitalize on using the terminology for your central information-sharing requirements.
DR. FITZMAURICE: Stuart, let me ask, do you kind of agree with the costs, that it would take 15 to 30 million dollars to start up a vocabulary?
DR. NELSON: My own estimate -- and I have to say this is my estimate, not the National Library of Medicine's estimate, my estimate is in agreement with Colin in terms of the start-up costs. I think that the National Library of Medicine has a lot of experience in maintaining vocabulary and we disagree about maintenance costs.
I do think that it is important that we have a -- that if this is something for the common good and I do believe that it has at least the potential of being something for the common good, that it is an appropriate area for government to take action. I say that as a citizen. I am not lobbying.
Because, you know, I don't see that my front end private practice in Westchester is beating down the doors for vocabularies that is only going to triple this work. You know, it is very interesting talking about the business case. I started my academic career at the State University of New York at StoneyBrook, which is notable as being the first hospital to open up with a computerized systems.
You didn't have to ask anybody. You used the computer system to look up the lab report because once they realized that they could say it is 20 minutes of time sitting on the phone waiting for a board clerk to read them the lab results, by just going to the computer, they went to it immediately. I think that was the first big win in computer applications in medicine. I think we are looking at the next one and each time we have to look at it, like David said, how does it help the actual practitioner.
You know, I think a lot of conscientious practitioners would respond to physician order entry because they would say, well, if we can demonstrate that this is going to improve patient safety, we will be in favor of doing it. But I think more and more, the longer it takes and the less tangible the results, the harder it is to justify -- for an individual to justify or an institution to justify a major investment in terminology.
DR. FITZMAURICE: David, do you have any comments regarding the role of government or the large fixed costs and the maintenance costs?
MR. LAREAU: I think the fixed costs to start a terminology from scratch just from our experience is probably in the 10 to 15 million dollar range. I would agree with that. I think the maintenance costs of the terminology itself are lower possibly, but the responsibility for quality assurance and cross mapping as it gets more widely used and the distribution and deployment costs rise and they become more of a burden than the terminology maintenance costs themselves, the cost of managing the deployment of it and the issues around that.
I would say that providers have been burned for so long by computer systems, by spending money that they had to throw out three or four years ago, that probably one of the most important things that the government can do is to say there are standards and here they are. I know that from our perspective that somebody who developed a terminology and put stuff on top of it and distributes it through vendors, when the department of defense announced they were using our stuff in CHCS2, that made it sustainable and all of the sudden many providers who were saying why should I even try a system with this. This thing might go away tomorrow. That was the setting of a standard sort of. That was a validation.
When this committee publishes the recommendations and the Secretary adopts them, the terminology standards, you will find some of the reluctance on the provider to pick one or the other will dissipate.
DR. COHN: I see Dr. McDonald has a question.
MR. MC DONALD: The question about cost of starting a terminology set, is that even plausible in this day and age? I mean, you have looked around the whole world and I don't know whether the terminologies need to be aggregated, but there is the American Chemical Abstract. They have got all of the chemicals. There are four or five places that are doing different things that cover a lot of these contents. Would it be that hard if you could start with them?
You are nodding "no."
DR. NELSON: I think the number I agreed with would -- is taking those things into account.
DR. COHN: Maybe I will try to ask the final question here.
We have sort of heard from all of you. One of the things that we are going to have to be thinking about as we move into this in future hearings is the issue of scope. I think on page 1, you see a whole variety of different terminologies covering a whole bunch of different domains, some of which cover more domains, others cover less. They sort of indicate that we need to sort of get rid of the word "atomic."
The issue is is that recognizing where we are and recognizing that there is a variety of different needs. The subcommittee and full committee have a choice of how we approach this. We can nibble off domain by domain or we can look for larger things that may cover more domains.
What advice in the year 2002 would you give the subcommittee and full committee --
Suzanne, do you want to start with that?
MS. BAKKEN: No surprise. I would not encourage you to be looking at single purpose terminologies that didn't cover the greater threats from the perspective of discipline or across the care studies as well. When we look at it from the area of patient safety and health care policy, it goes to multidisciplinary perspective and also being able to look at things --
DR. COHN: Dr. Chute.
DR. CHUTE: One of the notions of a web of aggregating concepts is that the source from which these concepts would be aggregated or high level classifications would be aggregated would be multidisciplinary and ideally interoperable and interlocking, along the lines that you have characterized previously.
The question then is what domain would one choose to be the most targets and I submit that, again, we are still dealing with a continuum interoperability kind of issue and I think at the end of the day these domains blend and merge among themselves so to enumerate almost silo notions of domain sources may be a reasonable starting point but I don't think it is where we want to end up in terms of looking at the problem.
DR. NELSON: I agree with Chris that it is not unreasonable to say that there is some low hanging fruit that you can establish single domain vocabularies or at the same time, there are other standards that we have used right now, that do not approach -- cannot be approached very well without a human intervention for mapping, that are high level codes on procedures. The International Classification of Diseases is an example. If you start -- say, okay, we are going to do these domains but at the same time these others need to start establishing sets of rules by which you can predictably find -- without a human intervention. I think that would be another area that would take some action.
MR. PRICE: [Comment off microphone.]
MR. LAREAU: I would say that from a practical standpoint, it would be very difficult to define that overarching, multidisciplinary home that everything is going to map to in any relatively short time period. I think that has to be the goal, but I think that just from a real world distribution perspective in terms of the systems out there, you have to start with the domains that are currently now widely in use and widely implemented in order to give those people a lead time to implement the domain changes.
DR. COHN: Let's take a break now.
[Brief recess.]
DR. COHN: Okay. We are running about ten minutes late or so, but I think we will be able to make up the time or go a little bit further into lunch.
This is our second panel. Our first presenter is David Berglund from NCHS. David, would you like to take the lead here?
DR. BERGLUND: All right. I will jump right in here. I am David Berglund, a medical officer at the National Center for Health Statistics. As most of you know, NCHS is responsible for maintaining ICD-9-CM, the diagnosis portion. I am going to specifically address the questions that we were asked to look at, looking at this open criteria for patient medical record information terminology selection.
Regarding the scope, first in grouping subsets of PMRI terminologies, there is a number of diverse areas that we were looking at here. The frame of reference that was being looked at was based on an original showing of different areas connecting it in the middle to convergence, which here was represented using SNOMED CT. One issue might be what is meant by convergence and how would this differ from clinically specific codes. Convergence can imply combining multiple systems into just one. It doesn't look like it would be feasible to use just one system, even one such as SNOMED CT, which has a lot of content.
On the other hand, convergence could refer to enabling interworking between different systems and interoperation. It could be things such as the capability to use a reference terminology as a basis for creating formal definitions for code sets or it could also refer to support for mapping to other systems.
For current purposes, it seems that SNOMED CT could reasonably be considered with the clinically specific group, rather than separated into a separate group for convergence.
Also, going on, the message specific codes and other codes might be out of scope based on the definition of terminologies. Code sets are not the same as data sets and message formats are also different from codes. It would be reasonable possibly to consider these separately based on different criteria. One question would be the extent to which things, such as message specific codes were already covered in other NCVHS recommendations.
There are a number of new groups or new terminologies, which could be considered for addition to the current list that we had and just to go over some of those here, considering new groups, again, it would be appropriate possibly to consider data sets as a separate group. Since they are not properly terminologies, that would make it more straightforward to use different criteria in evaluating them.
It might be possible to consider adding a group for medical literature classification, such as with the mesh headings, the medical subject headings. It is not clear whether that would really be in scope for patient medical record representation, however. Regarding new terminologies in general, the mesh headings do have a lot of overlap with clinical terminologies. They are one of the systems in the UMLS Metathesaurus. They do have a new concept basis also. For mapping between different systems that represent patient medical record information, the UMLS Metathesaurus has been widely used, mainly in research settings. It might meet part of the needs that have been described under convergence here with regard to mapping. However it is based on mapping between terminologies rather then being a terminology itself.
One system that has been conspicuously absent from consideration here is GALEN, the Generalized Architecture for Languages Encyclopaedias and Nomenclatures. It could be considered either with clinically specific codes or possibly with convergence. One of its advantages is a sophisticated ability to combine terms using the GRAIL language that has been developed for this. It was released in November of 1999 under an open license that allows free use through the non-profit organization OpenGALEN.
I will say it is not entirely clear how maintenance will work for it. It was most recently updated in October 2001, which was just released. Going on, looking at terminologies or other systems that should possibly be deleted or maybe classified, again, the data sets that have been listed aren't technically code sets when they specify data elements. Some of those elements may constitute code sets. It may be appropriate to consider data sets in a separate group. Some of these would include DEEDS for emergency departments.
Some of the nursing data sets also. Also, messaging formats should be considered separately with separate criteria. HL7 and X12N are really not code sets but specifications for messaging formats. Of course, these are important and distinguishing them from codes in terminologies is also helpful.
Going on, looking at prioritization for patient medical record information selection, first, the standards for diagnosis and procedure codes have already been specified, as well as standards for messaging. Since these are so widely used, this was appropriate that these be done first. It is important for those standards to remain current, for example, by expeditiously specifying the move to ICD-10-CM from ICD-9-CM.
The highest priorities for selection at this time, there is a need for clinically specific codes, as well as for drug codes and for nursing codes. The clinically specific codes, I would see as being the highest priority of those that do not have standards already specified. Why should things be a high priority here? Well, the clinically specific codes are needed for more detailed information so that that can be exchanged electronically for purposes such as claims attachments and also for clinical use.
Drug codes are needed. There is a lot of fast changes in this area. It may not be feasible to have a single standard. Using different systems as is now the case may be reasonable. Nursing codes are needed for more detailed tracking of patient care.
What should be low priority? Well, nothing can be too low a priority I would say. Sorry.
Criteria for selection of patient medical record information terminologies, first, changes to the preliminary criteria, I would see that different criteria are needed for different groups, for different subsets of terminologies. Selection criteria for messaging formats, data sets should be different from those for terminologies in general.
Classification systems that are intended to aggregate should have different criteria also particularly than clinically specific code systems. Many of the selection criteria that were listed were based on Cimino's desiderata. It should be noted those desiderata were intended for controlled terminologies with multiple purposes and these are really intended to be clinically specific. So, I would see many of those criteria as being best applied only for the clinically specific group of codes.
Briefly, I will mention some things. I do not see that the compositional approach or non-semantic identifiers are as necessary for some of the other categories as for perhaps clinically specific codes. To briefly go over some some things -- I am not going to go into detail on some of the other desiderata, which might be considered. Certainly there are some that are not specified here. Characteristics of the group of terminologies need to be considered in deciding which criteria are appropriate. That will just be rather broadly.
Also, the criteria specifying relationship with existing and proposed HIPAA standards in both working with message formats and in mapping with administrative standards is very important for consistency that is needed for the subsequent standards that may be specified to interoperate with the current standards. This would in some ways acknowledge the convergence is something of an issue if that is considered to be related to the interoperability.
Going on to ANSI accreditation, I would say the criteria should not encourage terminology developers to be ANSI accredited. However, it is important to maintain open meetings for standards development activities and to maintain timely and public notification of such meetings. On the other hand, I would not see it being necessary to use an ANSI consensus process for voting and balloting of new standards. That would not be likely to allow timely maintenance since consensus can be difficult to reach. Conflicted interested parties can push different ways for changes and, thus, stall the update process.
There would still be a susceptibility to influence by special interests issues of who should be allowed to vote, individuals or organizations, what stake they had in the process. The technical nature of the standards would limit the usefulness and the benefit of voting, I would say.
The established processes for updates for established standards shouldn't be modified and should not be subverted.
Some further comments, the one organization I am aware of that has become an ANSI accredited standard developer is the College of American Pathologists and it was proposed that SNOMED CT structure become an ANSI standard. Without going into any detail in that, I will say that even if the SNOMED CT structure were to be declared an ANSI standard, I do not at this time see it as being beneficial to require that all the terminologies that we have been considering here be distributed using this structure.
Going on, licensing for proprietary terminologies should ideally be reasonable and nondiscriminatory. That may also require that the costs for licensing be transparent.
Now, another issue for some areas it may be reasonable to use one standard for some purposes and another for different purposes, such as is likely to be done with drugs. It would, of course, be preferable to recognize such issues before mandating a standard, rather than having to rescind it later but certainly this is also one of the issues I would acknowledge that is taking so long in developing these standards.
DR. COHN: David, thank you.
Steve Brown, are you and Mike doing a joint presentation? Okay. Mike Lincoln is also there.
MR. BROWN: Thank you for the opportunity to be here trying to represent the VA's interest and perspective on PMRI terminology issues. Just to give you some idea where VA is and where we are coming from, the VA essentially has a complete electronic medical record in most of its 173 sites at this point. They have this computerized patient record system, CPRS, bar code med administration and other aspects of VISTA(?), that are widely deployed and we have gained a lot of experience in the field.
It features clinicians, centered data entry. So, for example, it was 82 percent of medication orders across the country that could have been by clinicians were in the most recent quarters worth of data. In the experience that we have gained looking at this process, we understand that we need terminology now and on into the future for patient safety issues, for decision support, for aggregating information for the purposes of research and management.
Then we are extremely supportive of collaborative efforts towards standardization and participate in a number of groups Given that background and perspective, I want to comment particularly on the questions that were directed towards us. In terms of the subset organization, we thought that the subsets were variable in how they were composed, perhaps the drug subsets reasonably consistent, but other subsets, such as clinically specific codes had quite a bit of variation in what was in and what wasn't in.
It wasn't clear to us why it -- exactly how that might be useful and we prefer in general a domain by domain approach. The convergent subset was also not entirely clear about what that meant. I think that a single terminology is not going to meet all our needs, whether it is proprietary or not, and that more likely convergence will occur not as a big bang, but as a series of incremental steps with interlocking terminologies with complementary content, as Chris wrote in the JAMIA(?) paper reflected the views of a number of people in this room and others.
So, I think our current expectation is is a series of interlocking terminologies to incrementally move towards the convergence rather than a big bang. One way to look at it rather than the boxes that were drawn in the diagram is how the Congress is starting to look at it and there we started looking at can domains be representative and they are being projected, labs, medication, communication. They can be there in the minutes, I suppose. We have written testimony as well.
But I think we prefer a domain by domain approach rather than -- there may be some other areas that are relevant for VA that are not representative that we would like to bring up, things like eligibility, military periods of service, items that are relevant, I think, to everyone would be an issue regarding DNR status and advanced directives that are really in the day-to-day clinical care matter, especially when people start to get sick.
VA specific aspects would be the VA's disability codes, but the idea of disability codes in general, I think, are one that we need to bring out.
MR. LINCOLN: We are facing this for our health data repository project, where we are having to prioritize the sorts of domains that we want to do first to try to get the most --
MR. BLAIR: For the benefit of those on the Internet, can you just identify yourself?
MR. LINCOLN: Mike Lincoln, Department of VA.
MR. BROWN: One minor point we would ask that you consider changing is we change the name of the FDA/VA Drug RT to the FDA/NLM and VA Collaborative Initiative. It is a minor point.
In terms of priorities, we feel that medications, labs and problems should have the highest priority. It is core medical data for decision-making in the VA. We feel there is a -- we have an immediate need for this in a structured format and we think that it would impact patient safety and care directly.
There are also some smaller items that would help us and those would be, again, the DNR, DNI advanced directives, those kinds of things; areas where the complete patient descriptions, as was previously mentioned, that are in free text are probably too hard to try to tackle right now. They would be important further down the road, but because there are some immediate low hanging fruits that we could apply to patient safety and quality of care initiatives, I think we would prioritize those higher.
In terms of general selection criteria, we would like to add the responsive field requests, in addition to being timely, we are trying to wrangle 170 some odd medical centers. There is a large local update penalty and we need to be able to supply centrally terminology that is responsive to field need in order to have any type of standardization.
In terms of the comment about relatively inexpensive to acquire and implement, we agree in principle, but we need further definition. We believe a pricing structure should scale and should not restrict information flow in any fashion. Open source, whenever possible or appropriate is ideal but surely other mechanisms exist that are reasonable.
In terms of general flexion criterion, we would like to say that it is not dependent on a specific vendor or a proprietary technology and draw a distinction there. Surely, vendor independence is a good thing, but XML and description logic are surely technologies and if they are non-proprietary, I think that being dependent upon those is probably okay.
MR. LINCOLN: One of the reasons we emphasize this slide is because we are required by federal record statutes to retain our patients records for 75 years after their last encounter, even if they have been dead for 74 of those 75 years. So, we have to have terminology standards that allow us to maintain the integrity of those records for the required period of time.
MR. BROWN: Regarding marketplace acceptance, we don't feel that necessarily equates to the quality that we need to provide care in our facilities and at the point of contact or the types of aggregation we need. Sometimes it does and sometimes it doesn't, but there might be new areas if there are significant weaknesses that are found by applying other criterion where new developments should be encouraged, regardless of what is currently in the marketplace, if it can support patient care quality and other types of decision support, patient safety.
So, we thought in looking at clinically specific terminology characteristics, we prefer a domain focus, rather than a broad, clinically specific set. We thought that many of the clinically specific criteria should actually be general criteria. We would echo what Stuart had to say about atomic concepts. One person's molecules are another's atoms or another's quarks(?) and it really has to do with the domain of discourse. We think that the issue really is pre and post coordination, rather than where our molecule ends and an atom begins.
Surely, there should be one circus(?) meeting performed, but one meeting per concept I think is basically implied. I will disagree with Stuart there. I think there are concepts and that is my concept.
In terms of relation to other terminologies, we believe that there should -- terminologies have explicit semantic models in order to support mapping. Mapping data coding systems are up and down between different levels of granularity. I will echo Dr. Chutes thoughts on aggregation. That is critically important to our managing our assets and doing population studies, for instance.
We believe that automated and semi-automated mapping should be the goal and brute force mapping is not a particularly desirable state of affairs and that with explicit semantic models, that is an important step towards achieving that type of mapping.
MR. LINCOLN: That is critically important for our HDR program again. Mapping will be a major stumbling block potentially. The Department of Defense is mapping their CHDS-1 facilities to the 3M Healthcare Data Dictionary and that effort has consumed $11.7 million just for the mapping to map only 31 sites. So, some sort of automation of mapping is really important and if terminologies can support that, it will be a big plus.
MR. BROWN: In terms of the implementation practices, we think the tools are a nice thing, but not absolutely a necessary criterion for selection. That is an opportunity for, you know, added value. Potential additions, explicit semantic models capable of formal representation would be one to consider. There are existing best terminology practices out there. One that has yet to be mentioned today is ASTM 2087 that may have been referred to as an ISO; the desiderata, you know, there are the usual suspects.
We believe that non-proprietary important and export formats should be supported. Even if there are, you know, licensing issues and the like, there ought to be a way to get information in and out.
Intellectual property issues need to be addressed. Patient data should never be put at risk. There should be explicit and scalable models of cost, opportunities for future migration. As I said, open sources whenever appropriate or possible is a good thing. Otherwise, they should be harmonized with other standards, interlocking as we have mentioned. We are highly supportive of collaboration between government and academic and industry partners regarding the ANSI question. We don't think it is necessary for all terminology developers to be ANSI standard developers, but we agree with many of the other presenters that the open process is one that is critically important. If it is a ANSI consensus process that is good.
So, basically, in summary, from our perspective, which is supporting electronic medical record across the country, we have an understanding of commitment to data standardization to help address our care issues and patient safety initiatives. We are working to develop an enterprise reference terminology strategy with some centralization and distribution of terminologies. For that, we will require high quality terminologies that we believe should be scalable, affordable and interoperable and interlocking rather than one giant, all-encompassing terminology.
MR. LINCOLN: I haven't written a paper order or paper note in about four years and on the Salt Lake VA's wards, which I think are typical. We have a single --
MR. BLAIR: Would you just introduce yourself?
MR. LINCOLN: Mike Lincoln again.
We have a single notebook on our floor where we keep any wet sign patient documents like operative consents. That notebook applies to the entire 32 bed ward. So, Steve and I are coming from the position of having to support this sort of highly automated electronic medical record environment with a great deal of clinician buy in and provide those clinicians with the functionality that they need to do physician support and patient safety and still not get in their way when they do their work.
MR. BROWN: I think we see this as a tremendous opportunity building upon the base that has been established with CPRS and BCMA to really then leverage our information systems if we can arrive at useful standards.
DR. COHN: Thank you.
Our next presenter is Brian Kelly.
DR. KELLY: Thank you, Dr. Cohn.
I am Brian Kelly. I am a practicing neurology critical care doctor from DOD.
What I would like to do in the next ten minutes is basically just sort of overview a little bit about DOD's position on terminology and data standardization. Just to give a frame of reference, the Department of Defense takes care of approximately 8.7 million beneficiaries in 76 hospitals and over 500 medical and dental clinics in the United States and 80 countries around the world.
We have over 80 various information systems supporting these various aspects of care and really are committed to data standardization as a core competency we must achieve and we must master to promote interoperability between these systems and other federal health and civilian systems. We have currently as part of those information systems major efforts going on to bring a common Internet portal to all of our beneficiaries and providers, as well as move to a web service type of environment which all is dependent on data standards.
We additionally have a major effort to develop a clinical data repository and a computerized patient record for all follow-up our beneficiaries, again, very dependent on data standards. Over the last year and a half, we focused very much on developing an enterprise architecture, which framed these issues.
What I would like to do is just try to answer the questions that were posed to us as panel members and just go through them sequentially. This was the initial frame of reference I think by the seventh briefing this morning. Everyone is more than familiar with it.
What we wanted to do was specifically address the question: Is there a better way to group or organize the subsets of PMRI terminologies? We look at this really as a question of whether you want to be a lumper or splitter. We can live with this grouping. I do feel that there is some merit in what some of the previous speakers have said about grouping issues on the -- domains. I think that does make sense from a clinical standpoint, but it really is -- and I think the point has been made very well that these are interlocking, interconnected standards and terminology sets. Grouping is not as critical as is the fact that they all need to play well together.
As far as adding new groups or subsets, again, I think we don't have any specific recommendations there.
As far as are there any new PMRI terminologies or groups that we would like to see added, the Department of Defense uses the third version of the dental code set as our dental standard and we would prefer CDT-3 as opposed to CDP-2.
In general also we feel that although we don't specifically feel strongly about the new categories, we would like to focus NCVHS's attention on the fact that we do look at the fact that there is still no accepted standard for identifying a person in his or her key role as a major barrier to the implementation and progress towards creating a PMRI.
Should any of the terminologies or groups be deleted? We don't know. They are all necessary and we feel like they will only grow over time.
To answer the second question that was posed, based on the existing graphics and the groupings, which categories should receive the highest priority, we did also have a little bit of difficulty understanding just what was meant by the convergence code set, but we do feel that the message specific and the clinically specific code set for us are the ones that are most important.
We also clearly use the drug code sets from the diagnosis and procedure code sets very frequently. We prioritize these highest because these are the ones that we feel are in most need of national consensus on and if we do achieve that, these will be probably the key enablers to a more effective timely ability for us to share information. These also are the code sets that we most frequently use and, again, are most frequently dependent on.
If we had to prioritize code sets as lower, we would put the nursing code sets and other code sets lower only because as the relative use in our facilities, they are used predominantly on the inpatient side and they are not used as much as some of the other code sets. That is in no way to say they are not important. We still need them, but if you had to ask us to rank them, we would put them in that order.
When talking about what deletions or modifications DOD would like to see to the preliminary criteria for the selection of PMRI criteria, one of the things that we would like to see is the encouragement of the use of repeatable model-based processes and told us to create and define terminologies, its concept and the relationships between concepts.
One of the key things that my staff feel very strongly about is that this really is key to us developing the more complex code sets and maintaining the appropriate linkages between these various code sets. So, we encourage this. We also would like to specifically on one of the comments made was to say that the relationships among concepts not only should be explicitly defined, internally consistent, non-redundant, but add the term and model base for that also.
When talking about what criteria need to be modified, we feel really that the criteria only that need to be modified should -- that we would encourage that the model-based method for the more complex standard terminologies used model-based methods, again, particularly for the complex groups. If so, what modifications are needed for different groups or subsets?
Again, we would strongly recommend that the selection criteria should be focused and emphasized for these specific groups and if they are very complex, again, getting back to the model based onset.
So, to address the question of ANSI accreditation. We do strongly encourage that future development of complex terminology be done using model-based development. While we don't feel that it is absolutely essential, we do think that the ANSI umbrella of organizations does add some credibility and some structure to this process. We do feel strongly that open meetings are a good process.
We do not feel that ANSI accreditation for well-established terminology and simple code sets is critical, but in general we support the ANSI consensus process for voting, balloting, on the exception of new versions and standards where applicable.
In closing, what other comments we have, the whole approach that NCVHS is taking to PMRI terminology -- we would encourage NCVHS to closely follow the other federal health and private sector health activities in the standards arena. Obviously, this includes the work being done by all the standards development organizations but also the work being done by consolidated health initiative, the various e-health initiatives and I know the AHA and the AMA and their effort in that regard.
So, these sort of conclude our ten minute comments on DOD's approach to terminology. Thank you.
DR. COHN: Brian, thank you very much.
Our next speaker is Peter Elkins from Mayo.
DR. ELKIN: Thank you, Mr. Chairman, committee members, committee staff and colleagues for having me present today. I am Peter Elkin. I am from the Mayo Clinic and I have a few things I would like to tell you about with respect to the questions that were asked.
My perspective comes from the fact that I have chaired the ASTM Standard Committee on Controlled Health Terminologies for the last about five or six years now, vice chair of the efforts to standardize health informatics within ASTM and I have also worked within HL7 as the co-chair of the Templates Group.
So, I thought I would start out with this graphic. I am going to just describe it for Jeff's benefit. There is a helicopter, a military helicopter, with a fellow who is climbing up a ladder and there is a large great white shark about 12 feet out of the water, trying to jump at the gentleman climbing the ladder. I thought this was the appropriate way to follow the DOD.
This has been voted the image of the year and for good reason. I think it does in some way reflect what we are hear about today and that is I see the helicopter as health care and health care informatics. I see the poor physician climbing up the ladder as he is trying to advance the field and I see this monolithic shark coming out of the water as non-comparable data, which is chasing us to our doom.
We are, as you can see, quite ahead of the shark so far, but -- and I hope that at the end of the meeting we continue to climb that ladder away from his impending reach.
MR. BLAIR: Is that a real picture?
DR. ELKIN: This is a real picture, yes. It is wonderful, isn't it? I will be distributing that later for interested individuals.
So, this problem that we are here about is an old problem. It is not a new problem. Florence Nightingale was quoted in 1893 as saying that "In attempting to arrive at the truth, I have applied everywhere for information, but in scarcely an instance have I been able to obtain hospital records fir for any purpose of comparison."
Of course there are a lot of goals and reasons for why we do this and we are trying to get granular encoding of patients' issues, problems and so forth and at Mayo we divide everything up in the following three ways: practice, education and research. We have lots of examples of how we do that, but as we support these processes of health care and knowledge acquisition, we need detailed granular encoding of the record in order to go forward.
The categorizations of the terminologies that were requested for us to talk about were by areas that were self-expressed by the terminology developers, it seemed to me. I thought there was a more appropriate way to do it and several of the other speakers from Chris to Sue Bakken to Colin and Stuart alluded to the same sort of an issue and Steve actually as well -- from aggregation of -- we need these levels of details for things like detailed underlying clinical knowledge, aggregations for DRGs, clinical codes, ICD and Chris talked about a network view of this.
I actually see that same network view as being the decision support that tells you where on the linear scale you wish to be. So, for instance, if you were designing from scratch ICD, you would pick the purposes that you wanted to use ICD for. You would have the different factors that were putting pressures on the system and that would enter into the decision rules by which you would pick the level of granularity from the underlying detailed nomenclature.
The real question is, you know, compositional systems, you know, to be or not to be. This brings together a great possibility of expressivity, but there is significant increased complexity with it, so that there is a tradeoff between complexity and expressivity with compositional systems that we could talk about for quite a long while.
In terms of adding things to the list, I would add in terms of new terminologies, the foundation model of anatomy, which I think is its appropriate name from the University of Washington, Cornelius Ross's group, Instructural Informatics. The Dermatology Lexicon Project and I guess I am on the board of that, so I have a little proprietary disclosure. That was sponsored through NIAMS, the NIH, that has that at the University of Rochester.
Then there is the patient safety coding system and actually that name is not solidified in stone. It is currently being contracted for development by the Agency for Healthcare Research and Quality. Then there is the Gene Ontology, which is created by the Gene Ontology Consortium, which I think would be useful additions to the list.
The next thing I would like to talk about is quality indicators. One of the charges was how to create the right sets of quality indicators for determining PMRI terminologies and we do have an ANSI standard for this in this country. It is ASTM E2087. I am going to tell you the three things you need to hear about this. So what? Who cares? And what is in it for you?
So what is clinical terminologies are now becoming robust enough for clinical use and there have been several examples cited around the table. I am sure we will have more. There are many competing philosophies on how these should be done and commonly there is a cost for purchase of the terminologies and even if there isn't, there is always a cost for using them.
The message that I really want to get across is the quality of the terminology directly affects its usefulness. So, who cares? Well, terminology developers care about the standards because they stipulate the features that are associated with quality and hopefully give direction for performing high quality evaluations of their terminologies.
Terminology users and purchasers should care because the general philosophy now is caveat emptor and this assists users in terminology standard. It assists users in both evaluating terminologies and assists users in evaluating the strength of evidence that they are presented with to support the use of a terminology.
Government agencies, like this one, are increasingly faced with selecting standardized clinical terminologies. So, what is in it for you as a member of society? Well, we think that standardization in this area and enforcing or, I guess, regulating terminology developers and to be conformant with ANSI standards provides more granular, sort of better understanding of clinical practice, hopefully, toward improved clinical care, that these improved data sets will be available for administrating the practice of medicine and linking decision support to the practice in a just in time way, like we all dream about.
In the end it will hopefully yield higher quality controlled health terminologies. So, there is an implementation guide. And I am just going to go through the top items on this. It is a very long slide. It is mostly for reference. But I just want to show you some of the things, point out, that aren't in the current criteria that you might want to be thinking about adding or use an approach that the NIH has taken.
Some of the general characteristics are that terminology should be concept oriented and I agree with Steve that that is probable and possible, that that means that they should be non-redundant, that they should be non-ambiguous and non-vague and that they should have internal consistency, that all these terminologies should be evaluated within their purpose and scope. So, having the purpose and scope of the terminology is very important. Some of the things that weren't in the criteria that I would point out are central to the usefulness of the terminologies are the coverage of the terminology.
Within that coverage, intended coverage, how comprehensive is it and how do you know? Then the explicit mappings -- we use these terminologies and we really purpose them. So, it is really important to know what they are pre-mapped to and what they are intended to be mapped to and what they absolutely can't be mapped to. That means that there needs to be systematic definitions or human readable definitions and there also needs to be formal definitions so computers can read them.
There needs to be explicitness of the relationships, so they are not vague and that has to do with how the rules of subsumption are supported. There needs to be an idea of what they mean by reference terminologies. Is it intended as a reference terminology and if so, can you identify the atomic portion of that terminology.
Then colloquial or some people have called them interface or status sort of terminologies or local terminologies, need to be supported. Then there are a number of things about clinical terminologies if you are thinking about compositional systems that have the expressivity to represent the full breadth of medicine and it is very important when you get into compositional terminologies to realize that you really need very robust and structured underpinnings in order to avoid unrecognized ambiguity.
So, compositionality, how that is done is very important and how you make an atomic concept and how you make a composite concept and how the pre-coordinated and post-coordinated terms are specified, what the rule base is and then what the types of atomic and pre-coordinated subsets that you allow within your terminology and you have support for.
Then this all gets back to normalization of content and semantics. Normalization of content is quickly when you know that every way you can say the same thing, you have -- that you can say exactly the same terms or concepts within the terminology have been specified in the way where you can identify them as the same. Then there is normalization of semantics, where you have to know that there is no semantic overlap between the different semantic operators within the terminology. Otherwise, you can have semantic operators within the terminology.
Otherwise, you can have semantic drift, which I believe one of the speakers referenced before me. So, an example of that very quickly were -- because this is one of the harder points, is shamelessly stolen from GALEN, is there were two ways to reasonably a clinician might specify laparoscopic cholecystectomy. One has a method using an endoscope and the other one uses device endoscopic or it uses device endoscope.
If there are multiple hierarchies as consistency of view supported, do you support explicit uncertainty? We are often not certain of what we are doing. There is evolving definitions over time. How this is supported is extremely important to meaning and make sure that representational form like the identifiers don't influence the usefulness of the terminology or the hierarchies.
There are a number of things about maintenance. Some of these were very well covered within the site of the criteria, but I would add a few more context free identifiers and persistence of identifiers. It was alluded to earlier in the presentation that there were a need for historical tables so that one could automatically identify the state of a term at a particular time as it was stored in the record so that the meaning and the semantics of that term at that time can be identified again to clarify the meaning of the record for longitudinal record clarity and identity purposes.
Then there needs to be clearer version control and obsolescent marking. We need to be able to recognize redundancy. We would like people to work toward language independence. Even in our own country we have many different languages that are spoken and we need responsiveness. It is interesting that was a big topic earlier. We talked to terminology developers in general. When we talked to them, pretty much all of them wanted update on an annual basis at that time and all of the users, absolutely every single one of them wanted overnight updates. It is the age of the Internet. We don't see why it can't be done.
We settled best we could in consensus and the standard, saying at least every three months. You know, evaluation, there needs to be criteria for evaluation and how evaluations are done and we need to point a way. Not everybody who is purchasing or using these terminologies is a scientist. So, we specified in this area the standard. Many of the criteria that are just good methods for getting generalizable results from an evaluation.
I am just going to kind of get through this typing. I apologize.
So, purpose and scope. Some of the questions that you may think of is what is the clinical area of intended use and then what is the primary use? There may be more than one. Is there persistence and extent of use expected or is it a one time thing that you are doing or a particular -- do you have longitudinality in your terminology? What is the degree of automatic inferencing intended so that people know what they can evaluate in terms of that and the mappings, as we spoke about?
Then what is the user/developer extensibility. This is talked about a lot in terms of how people like to say things. Then how is natural language supported since that is the user interface that is most commonly used. Then are there other functions intended, you know, specific physician support or linkage to postmarketing surveillance systems, et cetera?
Then what is the current status? Is it finished work? Is it product release? Is it something that is ongoing or is it something that can be evaluated at this point and at what level?
Then there are a number of measures of quality in terms of how people will utilize the tools that are available within the terminology if the value of the terminology is interlinked with those tools and one is sort of what is the precision and recall of the terminology and for -- within its context. If so, is it influenced by a standard search engine with the mapping process and does it have usability and has this been tested?
These slides are all available for you to read in greater detail. Then is it feasible? Has it been tested in real world environment or is it just something you think can be done and what is that feasibility demonstration? How closely does it align to my clinical environment? Then the validity and generalizability of any studies that have been done have to do with their gold standard, their relevance, blinding, randomization, test location, sample size personnel and so forth.
So, I am saying in sort of the Don Berwickian sense that we really need developers and evaluators need a comparable mechanism for selecting clinical terminologies, as does the government in doing future evaluations and in the Don Berwickian sense, let's put the stake in the ground in the 21st Century not the 20th Century where we have been pretty much all along.
So, just to recap very quickly, so what, while good terminologies can be useful, bad terminologies can cause harm. Who cares? Well, the terminology developers, consumers, clinicians and governments, of course, do.
What is in it for you? Following ANSI standards, we believe, gives you higher quality terminologies and the promise of improved clinical care through a better understanding of our practice and increased availability of decision support at the point of care. This has really gone through -- almost all terminology developers have had at this standard 19 or 22 countries in ISO participated. It is the ANSI standard in the United States. It is the HL7 criteria for use. It is currently a technical specification in ISO and it was used by the NIH through the Office of the Director for selection of their drug terminology.
At that time, they built a little network or set of slides for this that could be easily filled out. This can be available electronically to the committee if this is useful and was used to evaluate a number of different terminologies for their drug development needs, drug terminology needs.
Thank you very much.
DR. COHN: Okay, Peter. Thank you very much.
Kent Spackman, College of American Pathologists.
DR. SPACKMAN: I am Kent Spackman. I am a professor of pathology, professor of medical informatics and professor of public health and preventive medicine at Oregon and Health Sciences University -- Oregan Health and Science University. I still can't get that right. They are changing the name on me.
I am also chair of the SNOMED International Editorial Board. What I would like to address today is the things that the committee has asked. I may not do it in a direct way to all the questions, but I do want to address the scope of PMRI terminologies and categories of terminologies, criteria for selection, particularly with a focus on an analysis of the user requirement and then an approach to integration and convergence.
From the user perspective, there are really only two main categories of terminologies. There are comprehensive, integrated clinical terminologies and there are those of limited scope. Here I am echoing what Colin Price said earlier. Those limited scopes may be domain limited, limited to drugs or nursing or devices or emergency departments or they may be use limited, that is, messaging or bar codes, reimbursement, user interface. But fundamentally, the users of our terminologies really need a comprehensive, integrated role.
So, how should we categorize or group these? What I think should be done is that we should list the user needs and requirements and prioritize them and then the committee's task as stated, that is, the selection of PMRI terminologies really needs to add a task to recommend the development of an integrated whole, the testing of that whole against the requirements and a revision and updating to meet those requirements.
As many of the people here have noted, we need to have -- many people have said interlocking, but I think we are talking about the same thing. When they say they don't know what "convergence" means, they go on to use the word "interlocking." But fundamentally some work has to be done in order to meet the user requirement for interoperability and that work is what I would call convergence.
We need to think about who are the users of the terminology. Many people have said that terminology is not useful in and of itself and I agree entirely. We have to consider the requirements of software developers and vendors and some software developers aren't vendors and some vendors don't do the development. But the terminology ultimately gets used in software. It is a software enabled environment where we anticipate the use of this stuff that we are producing.
There also are information technology support staff and then the clinicians and other end users and the users of secondary applications, people who aggregate and analyze the data. All of those users' needs need to be considered as we think about what are the requirements those people have for terminology.
The SNOMED Clinical Terms experience is based on
-- what I am presenting to you here is what we have developed as a set of user requirements and what we are judging our work against and based on the feedback that we have got from our users. So, we have got input from an industry advisory group, convergent terminology groups in nursing, pharmacy, pathology and other clinical areas, alpha testing of the structure and the content by 42 different organizations in six different countries, feedback from large enterprises, like Kaiser, HCA and the National Health Service in the U.K.
We have also published our methods for feedback on the web and in peer reviewed forums and we anticipate that we will continue to do this entire process. There is another criterion that I don't think anybody has emphasized and that has to be the degree to which the software vendor community has acknowledged or recognized the value of the terminology by licensing it and declaring an intention to use it. This is a slide that represents a pie chart of the software development organizations and vendors, enterprise-wide computerized patient record systems. The size of the pie is relative to their market share from a study by Sheldon Dorenfest(?) and the ones in blue are the ones who have licensed SNOMED CT for deployment and development.
In laboratory computerized systems, again, the number of organizations that have licensed SNOMED CT. So, there is clear evidence, even though this is relatively early. SNOMED was just released. SNOMED CT was just released in January of this year. There is clear evidence that the software development and vendor community sees this of value.
Now, this is not a one way passive process either. As vendors develop systems using SNOMED CT, we actively solicit and respond to their feedback and their requirements and priorities are closely followed. This is a direct result of SNOMED's recognition of the importance of vendor and user requirements. We are not off building this in an ivory tower. We are to meet a set of needs.
I don't have a whole lot of time to go through all of these. So, user requirements for PMRI terminology, we have a document on the web and the web address is there. You can download that document and read it if you want all the details. We have five main categories that I am going to mention here and then I am going to skip over the slides because I don't have time to do all of them. Please feel free to ask questions about these.
There are user requirements for patient records and software applications. There is the general requirements for a terminology that -- the desiderata. There are software implementation support and maintenance requirements. There are requirements specific to particular user communities and then there are requirements that are determined by realm specific strategic imperatives. So, what Colin was referring to earlier about the NHS's strategic imperatives for cancer and heart disease and so on, we would anticipate needing to be responsive to the realm specific strategic imperatives within the U.S. as well.
So, I will, for purposes of time, I am going to skip over these five items and move to the item of ANSI standardization. We think PMRI terminology developers in general should be accredited standards development organizations and should be required if not formally an accredited SDO, at least required to provide an open consensus process for input to revisions and update.
An ANSI process, such as the canvass process or the accredited standards committee process meets this need. CAP is an ANSI accredited SDO and the structure of SNOMED CT has been proposed and validated as an ANSI standard by the canvass process. We had 84 percent favorable response rate to that. We are now in the process of revising the standard based on the feedback that we got and we are following the open process for that structure standard.
I would like to focus the committee's attention on the pitfalls of approaching this as only a process of selection. Approaching this as a process of selection presumes that selecting some grouping or subgroup of the PMRI terminologies listed will somehow meet the user's need, but we see no evidence that users' needs can be well met by merely a collection of PMRI terminologies. Rather, users' needs require an integrated whole. So, selection of a small group of complementary terminologies appears to satisfice, "satisfice" being a term coined by Herb Simon. It means obtaining an outcome that is not optimal, but is good enough. We believe that this, instead, leaves significant needs unmet and from the user perspective, it is not even satisficing, not even good enough.
There are lots of reasons why integration is necessary. Many different types of concepts have to be linked to each other. For example, procedures that use particular devices requires a linkage or an interlocking, if you will, of the procedure terminology with a device terminology. Any terminology that deals with allergies has to link to drugs and substances and things that you can be allergic to.
Common concepts occur across many different clinical domains. Symptoms, signs, disorders and interventions all occur across different professional domains. Many different uses and users have to rely on the same information, from documentation, decision support, reimbursement, research and quality related activities. So, it is folly to think of merely as a subset of terminologies as meeting the needs of users.
Let me address cost as a criterion. From a national perspective, it is far cheaper to develop an integrated terminology. Cost of development and maintenance of an integrated terminology are dwarfed by the cost of implementation of systems that use it and without an integrated terminology, the opportunity costs and incremental costs of system development and maintenance are orders of magnitude greater.
I think this echoes again the experience and the perspective from our colleagues in the U.K. Our public policy makers have a sense of urgency about this. They say in a speech to the National Alliance for Health Information Technology, Nancy Johnson said if you don't, we will. That is, if you the industry don't standardize terminology, we will, the government will. The quality of health care at this moment is linked to our ability to mobilize technology and we must start with the assumption of interoperability and in the absence of an integrated standard PMRI terminology, you do not have interoperability.
So, what would we recommend? I think an approach would be to choose the best of breed immediately. SNOMED has consistently been rated No. 1 by independent third parties. The NLM sole source solicitation site at SNOMED is the only source capable of providing the necessary services. The failure of a good faith effort -- negotiation effort between the NLM and the CAP should not deter NCVHS from recommending the obvious choice that meets users' needs and is in the best interest of health care.
This is probably the most important point in this entire presentation. The CAP stands ready to work collaboratively to achieve an integrated requirements-driven terminology solution. Our current major collaborations include Kaiser Permanente. John Mattison says, "Kaiser is rolling out an electronic health record system throughout our entire program, using SNOMED CT. Kaiser also has several other clinical systems that are already using SNOMED including pathology in our data warehouse."
Colin has already presented to you that the U.K. National Health Service, subject to the successful development and testing after the 1st of April 2003, anticipates requiring new systems to be developed, using SNOMED CT.
CAP SNOMED as the terminology that has the best track record in developing and delivering what users really need in a clinical terminology. In the latest edition, SNOMED CT draws on a combined 58 year research development and leadership of the CAP and the U.K.'s National Health Service. It integrates input and validation by more than 350 different contributors from Kaiser, the CAP, the American Academy of Ophthalmology, the American Veterinary Medicine Association and a long list.
SNOMED has been chosen by 48 industry leading companies and the CAP is strongly committed to continuing its 39 plus year effort in this regard. Here is the diagram with SNOMED Clinical Terms as a convergent terminology. In blue, I have marked the ones that are either fully or partially integrated or mapped from SNOMED CT. So, it is entirely possible to take, for example, NIC and NOC and NANDA and other nursing terminologies and integrate the concepts within the structure of SNOMED CT. In fact, we have agreements, formal agreements, with those nursing terminologies that have dealt with -- explicitly dealt with any of the intellectual property issues that are required to be dealt with and that enhances this converged integrated whole.
In terms of the relative size of some of the other terminologies, if you look at the size of SNOMED CT relative to ICD-9-CM or CPT for procedures or some of the nursing terminologies or ICDO within the morphology section, there is an enormous amount of content in SNOMED CT. Each of these other pieces represents a small piece in what you might regard as a mosaic and you could think of them as interlocking pieces within SNOMED.
We recognize, however, that SNOMED is not a hundred percent complete and we think that SNOMED needs to be integrated as the core reference terminology with some other terminologies; for example, with some other clinically specific codes, like LOINC, with drug codes, such as the virtual clinical drugs and the U.S. proprietary and clinical drugs in the FDA/VA effort, with nursing codes, such as PNDS, NIC and NOC.
We also agree that we need to map these core clinical concepts to classifications, such as CPT-4 and ICD-9-CM and CDT-2 and 3 and ICIDH and so on. Then we would propose that we build subsets and extensions to support linkage or modeling of domain limited and use limited terminologies and if the committee can focus its future energy and resources on continuous improvement and deployment of a core versus the fragmented development.
The final slide, I think the committee could make major steps forward if it would require a proven maintenance infrastructure, prevent analysis paralysis and disruption of a forward trend with industry and providers for the perfect or the promise of something unproven. The marketplace is moving to deploy SNOMED CT now so that clinicians, researchers and the public can reap the benefits sooner rather than later.
We will get interoperability, reduced medical errors, improved quality of our nation's health.
Thank you very much and appreciate any questions.
DR. COHN: Kent, thank you.
Questions from the subcommittee? Clem.
DR. MC DONALD: On the list of all the vendors, who have made license agreements -- the question is is how many of them have made the license agreements to try it and see what it is like and how many have incorporated it. I ask this -- and then if you could also say how much do they spin on it in terms of their licensing fees because that may be the same answer.
DR. SPACKMAN: They have all licensed it for both development and deployment. They have had it -- some of them have had their licenses since January, but many of them haven't. I can't answer for each individual vendor. I don't think they will give me the amount of money that they are spending on development.
DR. MC DONALD: No, no, no. How much have they spent on the license fees for SNOMED?
DR. SPACKMAN: The license fees, I think, for -- an initial license fee is $3,000. That is about what they have --
DR. MC DONALD: Would that be the final license? I mean, what is the difference between an initial and the next one? Is there anymore cost to the vendor than that or would there be if they went further?
DR. SPACKMAN: When they deploy, then there is a cost for deployment in various medical centers. Those costs are very low and very reasonable.
DR. MC DONALD: Could you quote those because I don't want to bring it up in this audience, but some of the costs that we encounter weren't low.
DR. SPACKMAN: Some of the costs that you have mentioned publicly in this forum are definitely incorrect and orders of magnitude out of scale.
DR. MC DONALD: I have the e-mail from your organization with those costs.
DR. SPACKMAN: Well, I can tell you that the numbers that you have quoted to this committee are orders of magnitude out of scale too high. We have got the numbers available publicly so you can go and check them out.
DR. COHN: Where is the site for the public charges and all that? This has been a recurring issue. Is that on the web site?
DR. SPACKMAN: I can get that for you later, but
I --
DR. COHN: I just heard you mention it publicly. So, I was just following up on that.
MR. STEINDEL: One of the purposes of this particular hearing is to explore criteria for us to develop terminology, criteria for selection, which we will do in the context of later hearings. One of the issues that came up in the -- or one of the points that came up in the earlier set of speakers was that they felt the cost of developing the terminology was on the order of 15 to 20 million dollars and people were confirming that that seemed to be a very good figure and the cost of maintenance, Colin was stating in the order of $15 million and other people were stating were somewhat lower, though they didn't give specific figures.
What I would like each one of the speakers to address is their comments with respect to those costs. Is that something that the NCVHS considers reasonable costs for a terminology.
Brian, if you want to start, I will just go from that end.
DR. KELLY: Brian Kelly, DOD. It would be hard for me to really confirm that. I can tell you this clearly is a very expensive effort to develop terminology. DOD tries very hard not to develop DOD specific medical terminologies for just that reason. We obviously have to deal with the fact that we interact with DOD Health as the subset of big DOD and they have standards that we must modify our systems to. But from what we have seen, the number would be fairly large, but I couldn't tell you whether 15 million is accurate or not.
DR. BERGLUND: I would also have a hard time verifying that. I would certainly acknowledge that development costs for terminologies can be very significant. I will say I would hope that such development could be done without that level of expense, but I won't try to give any specific numbers at this point in time.
DR. ELKIN: I think honest benchmarking needs to be done to come up with the exact number, but there are two things that could make the process much less expensive. The first thing is using automated tools in order to generate the description logic. Once you have your atomic content -- it is possible that we published this I think in 1999, to generate many, if not the lion's share really of the description logic algorithmically, which decreases costs exponentially.
The second thing is we are in favor of a model that was originally developed in the GCPR process, which used teams of modelers in order to start to create terminologies. We added one additional thing to that model in our group, which looked at taking academic units that were the experts in the field and creating editorial boards that would give them credit like being editor of a journal and being able to advance junior faculties' careers by serving in that position, which might defray some of the cost at the bottom point.
I think there are strategies that can be used that in an open fora that may help to decrease the costs of terminological development for any organization or group that should want to do so.
MR. LINCOLN: VA thinks that having good tools that employ common technologies, such as description logics can reduce costs. As Peter said, I think it would be a good idea to get some benchmarking of terminology development costs. We have tried to do a little bit of that in the GCPR effort, but those efforts were preliminary.
MR. BROWN: What I would say is terminology for what? What are we talking about here? Are we talking about the all-encompassing, try to put everything into it? I think we have already disagreed that that is a likely approach and it may not be all that hard for us to agree upon one of thirty ways to say "yes," "no" or, you know, periods of service or PNR codes or something such as that and there are other many more complex tasks.
So, I don't think one figure can be applied because there are different jobs to be done.
DR. SPACKMAN: This is Kent again. I think Colin's estimate had to do with a global integrated terminology. We are talking about something that meets the needs of U.K. and Canada and the U.S. and Australia and New Zealand and then has translations to other languages and so on. I mean, he is -- you know, when he says that that is the cost.
All I can give you for sure is an order of magnitude; you know, 10 to the 6th, $1 million per year is clearly not enough to maintain that kind of a terminology. Ten to the 8th is overkill, you know. A hundred million dollars is more than we would need to spend on that. Ten to the 7th is somewhere in the order of magnitude of what it would take to maintain. I think anything other than that is fine tuning of what are you doing, what needs are you meeting, what are your priorities and what do you do first and what do you do last?
I think a lot of fusting(?) around the edges of that is really missing the point.
MR. BLAIR: Kent, could you also comment on the suggestion of some of the other testifiers that costs can be lowered by the use of tools for description logic?
DR. SPACKMAN: Sure. CAP has been using description logic tools for development of the terminologies since 1996. We have also done a huge amount of work with Kaiser in using those tools and in training modelers and the focus of that effort is integration and interoperability. If we didn't have to have integration and interoperability, we might not need to have a description logic foundation for the terminology and it would be very much easier to just start adding things into the terminology and, you know, just decide, well, we don't have that one yet. Let's add it. If that is all we are talking about, costs are really low.
But actually committing to an integrated clinical terminology that has a formal logical foundation and uses description logic or something like it, actually is that commitment is what adds the cost because it takes about six months to get a reasonably intelligent, well-informed clinician from zero to being a productive model or using description logic in a clinical terminology. That has been our consistent experience with people within Kaiser, within the NHS, within the CAP over the last five years. This has nothing -- it doesn't say anything about the capabilities of the individuals. We think we have got fairly capable individuals who do this.
It is the complexity of doing the job. The tools themselves can be improved to make that job easier, but actually committing to using those tools that engenders a huge amount of this cost of building an integrated solution. So, yes, I am all for having better tools. But it is the integration challenge that really adds additional cost and it is a challenge that isn't met by just selecting a set of terminologies that appear to interlock in some way.
DR. COHN: Jeff and then Michael.
MR. BLAIR: By the way, this panel, like the previous panel, has been very rich in the suggestions and information and guidance that you have given to us.
One of the new thoughts that came out of this panel here was the idea that while the cost of developing a terminology is an important cost to consider and which would be reflected in licensing or royalty agreements or whatever or federal payment to make it available at little or no cost, that we might be blindsided -- I love that phrase -- by the fact that the real cost to vendors and users is the implementation costs, which could be far, far larger.
Since a number of you represent not only developers but users of terminologies, I would like to know whatever you could tell us about what your perception is of those relative costs and what factors, tools, aids or other things can a terminology developer provide that would help to reduce the implementation costs. So, I would like to hear from each of you that wish to comment.
DR. SPACKMAN: I definitely have a comment. This is Kent again. One of the things that we have focused a lot of attention on is building predictable structures that vendors can take and import into their systems. By predictable, I mean that we are not going to be changing the structure release to release, that we give them a well-vested set of specifications for how we are going to be delivering the terminology and what the purposes are for the different pieces.
The other thing that we have been focusing on is how do you make the terminology more implementable. So, just by providing a concept and the name of a concept, you are not really providing people much help. So, some of the things that we have had to add are things like special subsets, subsets for primary care physicians, subsets of the terms or the descriptions that are focused on a particular realm. So, you know, in the U.K., we have a subset of the terms that utilize just U.K. accepted spellings and in the U.S., a set of U.S. accepted spellings.
There is a long list of those things that I could go through, but basically as the vendor community has taken SNOMED and tested it and given us feedback, they have told us, look, we can't implement this unless -- we would really appreciate it if you would add this additional feature. You know, we need to know, for example, what are the -- all the different concepts that might be referred to by the same term and then what would be the preferred concept in a search application.
So, when I type i-r-i-s, I want to get back the eye structure and not the flower, even though we have got the flower in there that if you are in a clinical application, you generally want the eye and those sorts of structures. There is a long list of structures and, you know, I could go into it in more length if you want, but SNOMED has been developing indirect response to feedback from the software implementers to ease the transition from just a set of codes and terms to an implemented interface. We are also drawing on our experience or the experience of our colleagues in the U.K. Colin was able to share with you about the fact that the clinical terms version 3 didn't get widespread uptake and there were some reasons for that and we have tried to learn from those lessons so that SNOMED CT will be able to overcome those barriers.
It has to do with all of the implementation issues that he has been studying. You know, you do it as a big bang or one piece at a time. You know, exactly how does implementation take place and how do you deal with all of the users legacy data. That is another big issue and how do you migrate legacy data?
These are all issues that SNOMED has been focused on and we consider part of the integrated terminology task. If what you think we are about is putting a code next to a term, you have got a very narrow view of what the integrated terminology task is really all about.
MR. BLAIR: I would like to hear as well from the other folks. The thought behind my question, of course, is the criteria for selection of standards, whether we have left it incomplete because we haven't fully indicated in that criteria what the implementation costs are, aside from license fees.
DR. KELLY: This is Brian Kelly from DOD.
Just sort of in general regards to that, I think that the actual expense of the -- the most important thing to do here is to pick the best standard or standards and move to them as quickly as possible. When you look at total life cycle costs of all of our information systems among all of our federal agencies and civilian health care agencies, getting to common standards will enable interoperability far greater than anything else will and will decrease total life cycle cost. That is not to say that we shouldn't strive for the lowest possible licensing fees of these standard terminologies but in my view those licensing fees are going to be a very small percentage of the implementation costs.
I think you also want to look at the qualitative benefit of having standard data. It is, I think, at the epicenter of all of our patient safety initiatives and all of our qualitative ways for improving health care. I think it would be shortsighted to worry too much about -- to not pick a standard because of cost because I think it is much, much more important to pick the best standard because of the other reasons.
DR. ELKIN: Peter Elkin from Mayo Clinic.
I took your question, Jeff, to be more what are the human factors issues that need to be thought about that may influence the cost of implementation. It seems like sound application of human factors engineering principles, user center design, both in the terminology and in the tool sets that are intended to use that terminology can greatly affect the cost of implementation, which I think the group has agreed is the vast majority overall of the entire cost of the terminology.
I would add one more cost that I don't want to get lost in the shuffle because it is a downstream cost, but probably the most important one and that is if we don't have accuracy of data, if we get ambiguous data, it will cause harm, harm to our systems, harm to our decision support efforts and harm to the individuals who are entrusted to us for their care.
MR. LINCOLN: This is Mike Lincoln from VA. Steve and I have been chatting about your question a little bit and VA also sees tangible benefit standards as does Captain Kelly and Peter and others and Kent Spackman. For us, migrating our legacy systems to new terminology standards is a very significant issue. Even if a terminology standard was free, we would still be faced with substantial costs to migrate. In fact, I think Steve has written a paper called "Migrating -- Steve wrote a paper about the cost of a free computerized patient medical record implementing CPRS at Nashville.
So, one of the big components of that cost is the cost of mapping and converting your legacy system in a sensible way from its current environment to the target information system environment. If there are tools and methods that the terminology provides to do that, it will be a big advantage, I think, to make the terminology solution work. So, the mapping issue, for instance, that we face with our health data repository and I know DOD faces with its CHCS2 clinical data repository, those are very significant issues and some way to ameliorate those would be good.
MR. BLAIR: Thank you, Mike.
Steve, would it be possible for you to either send us electronically or in some other form a copy of the article that you wrote?
MR. BROWN: Sure. I might add to Mike's comments. We have recently had some experience mapping to LOINC in our lab environments and I think the cost of implementation vary with where are you and where are you going. I mean, we are not talking about the same A and the same B necessarily. So, for us, we were given a directive from our undersecretary to map the LOINC across however many sites it is today with the actual vista systems in it. It is 130, something like that.
MR. LINCOLN: 128 consolidated vista sites.
MR. BROWN: And, you know, in calling around and looking at the overall labor involved, it was a couple of weeks at each site for an ad -- our sort of lab technical people to actually do that. I can't comment on how much time it took, programming effort it took but I mean it certainly wasn't anymore that, roughly five FTE, it all added up to, I would guess. Because we already had an existing lab system that was fairly compatible and with migration to LOINC and so that wasn't a terribly painful implementation.
I can imagine that many would be. So, again, we are not talking apples to apples, necessarily, here as we start throwing out these guesses at numbers. That is an example of one that was particularly easy that we expect to have huge benefit and in areas where we are not as well developed, it would be a different story.
DR. COHN: Clem and I think, Mike, you have a question, too?
DR. MC DONALD: This is sort of a mixed question and comment. The implementation as I heard described really covers a whole broad spectrum of things and I am not sure if everyone in the audience understands how broad the spectrum is. It costs us to implement the new version of CPT, like a nickel. I mean, we take the disk and we put it in and it loads in. I think some of what we are talking about implementation is sort of a radical degree development of all practice, to use an extremely detailed set of codes instead of English language. That is going to be very expensive. In fact, it may never get there because that is one thought. If we could really get all the narrative text, have it coded, but we have to recall that that would mean physicians or other care providers would have to make a lot of distinctions and code levels much beyond what they have to do now. That is outside of the coding question or the quality of the coding. It is just a big, big open question, an interesting one we are all trying to push toward it. But I think that is a high cost.
So, that is one set of it. I just wondered if people -- I guess we kind of heard the spectrum with the implementation here, but I think it depends on what you are talking about. If you are talking about radically revolutionizing health care data recording, it is going to be real expensive. That is not really just, you know, independent of the code system.
The second thing is we started to focus on codes and codes always have names or strings on them. That is the thing, I think, that we really want to come up with somehow. We want to come up with codes and then the industry may get -- embellish all kinds of tools on them as they have in other industries, like with NDC. I think that is a good example where NDC is just a dumb code, especially dumb. I shouldn't be -- but an industry sprung up that created the hierarchies and the linkages and all the other kind of things.
We were kind of an industry with a lot of things if we could get this nidus or this core of codes. SNOMED has some wonderful additional knowledge base in it. I guess we at least ought to decide among ourselves whether what I am saying is right. We just want to decide on what the code should be and let the industry put in the extra value on it or whether we want to buy a big extra value thing or not buy it, I mean, you know, buy into a thing with a lot of construction of other knowledge bases on it.
DR. COHN: I don't think we need -- did you want the --
MR. MC DONALD: Well, if there are comments on that.
DR. COHN: I think we will not solve this problem at this time.
MR. MC DONALD: Well, just to clarify the definitions we are talking about.
DR. ELKIN: Peter Elkin, Mayo Clinic.
I would just like to say one thing about this. I think it could be construed from Clem's comment that clinical specific terminologies are not a good idea and I think that is wrong. I think that, you know, although it is very unlikely that Pickless(?) will solve the interspace problem for defining the concepts within the detailed health record. I believe that natural language processing and post processing techniques can do that without a radical change in practice.
MR. MC DONALD: I didn't mean to imply that. It was just the implementation cost spectrum I wanted to --
DR. SPACKMAN: I agree with Peter's comment that the -- what you have described as the far end of the spectrum that nobody really thinks is realistic today, but there is a nearer end of the spectrum that is directly connected to the benefits that we expect to get out of additional information. And I think even that level of implementation will be extremely costly.
DR. COHN: Mike, do you have a final comment, question?
DR. FITZMAURICE: Both DOD and VA have a good history of developing components for electronic communication, components for electronic patient records. CHCP-1 and 2, DCHP, which has gone to Vista. Is there collaboration in the vocabulary development and applications between VA and DOD? When you go about making choices for coding systems, terminologies, vocabularies, do you share information, evaluation criteria with each other?
Secondly, have you considered using SNOMED to collaborate for sharing the lab data, drug information data, physician's notes and so forth, so that a VA physician treating a former military patient can see information from best medical episodes? Do you collaborate on sharing your choices of vocabularies? Then, secondly, have you thought about each -- using SNOMED in order to collaborate with each other?
MR. LINCOLN: Well, Greg Donham(?), who is the program director for Federal Health Information Exchange, the program formerly known as GCPR, will be here this afternoon after 2:30. Greg could probably also comment on this, but FHIE represents sort of the main area of VA to DOD collaboration in data interchange right now.
I think the second part of your question related to how much is VA and DOD either currently using or considering using SNOMED to facilitate that data interchange. Captain Kelly can probably speak more clearly for DOD. In the case of VA, we don't currently use SNOMED as part of our electronic medical record in any significant way. Most of our current files that we use for drugs and labs and person demographics, very similar to the CHCS files, were developed in house. Some of them like our CPT and ICD and Lexicon Utility files are based on national standards.
For the ones that aren't based on national standards, like our document titles and so forth, we are currently working to map those to emerging standards that we think will allow us to interoperate at least between our VA facilities, our different vista sites and, hopefully, between VA and DOD. But we haven't really looked at SNOMED as a way to do that in particular.
DR. KELLY: Just on the DOD side, we have actually worked with the VA and done an initial mapping of all of our data standards and there is actually fairly high -- good agreement on many of our common standards. Both of us are actively participating in the CHI that I know you will hear about tomorrow. We are looking at, you know, being, hopefully, sort of one of the poster children for them, as far as the sequential adoption of various standards as time goes on.
Our CHCS-2 effort has used a 3M health data dictionary. So, it hasn't really gotten into all of the aspects of SNOMED CT and I just don't think we have made any commitment one way or another to its use at this point.
DR. BERGLUND: This is David Berglund.
I would like to just comment on that and perhaps ask a question at the same time. I was going to comment earlier, too, that I would like to reiterate that I would like to see it that licensing be reasonable and non-discriminatory for proprietary standards and that licensing costs then be transparent. Certainly I would be curious about whether anyone might have any kind of an estimate or a guess as to what the cost would be for licensing SNOMED for such a broad use as to allow collaboration between the VA and the DOD in that there would be a huge number of users who would have to be involved.
I would put Kent on the spot and see if he could respond to that, but I am not sure if that is very nice of me, but -- Kent, would you like to comment on that?
DR. SPACKMAN: I don't mind the question. I mean, I am not -- I don't keep in my head, you know, the figures. First of all, I don't know how big the VA and DOD are and, secondly, I don't have the licensing fee figures in my head. If you call Diane Ashland and ask that question, she will be able to give you an answer.
DR. BERGLUND: And I believe that CAP is moving to be more transparent in their licensing and I am glad to see that.
MR. BLAIR: Could I just maybe with this discussion -- I think all of us are very, very interested in what the real costs are, but could I just get one clarification from the group, which was the thrust of my question, but maybe I didn't ask it clearly. When we talk about using the cost of a terminology as a criteria for evaluation and eventual recommendation, I thought I was hearing from this panel, that in addition to licensing costs we should also be looking at implementation costs as well, to the degree that we could get that information.
So, I would like to ask just each of you should we expand criteria for selection to include implementation costs, assuming we could get that information, as well as just licensing costs?
DR. SPACKMAN: My view is that the cost of implementation of a standard if it is really a good standard would be influenced most by what comes with the terminology to assist in implementation. So, it sort of begs the question that Clem asked earlier. Are we just talking about this committee making a recommendation about codes and a name attached to the code and then leaving all the rest of it to industry or are we talking about doing what I think my own view is more necessary, to accompany those codes and strings with some assistance for the implementers so that their implementation costs are lowered by this, by a central effort that meets common needs, rather than leaving it up to each person or each individual organization to solve by itself?
MR. BLAIR: Let me still -- try to stay focused here. Are you saying that we should add implementation costs to the criteria?
DR. SPACKMAN: I think that the implementation costs aren't directly connected to just the selection of a set of codes. Right? The implementation costs and the potential savings in implementation costs can be connected to other aspects of what a terminology can provide. So, the ability to provide those other aspects, I think, should be a criterion that the committee considers.
DR. BERGLUND: This is David Berglund. I would just like to comment also.
Clearly, the implementation costs can be significant. I will say that they could vary a lot, depending on the user and what they already have. So, it is very difficult to get an accurate estimate of this across the board. So, I am not so sure that that is as necessary. Certainly the benefits of implementation are another big factor and how much those would mitigate the cost would be another thing that might perhaps be taken into account then, but on the other hand, that is very hard to sort out and in some ways is rather abstract.
MR. LINCOLN: Mike Lincoln from VA.
You know, VA looks at several costs. We look at the acquisition cost. Since we have about 50,000 clinicians, even a $100 per year acquisition cost and recurring license would be a significant budget item for us. It would be 5 million bucks. we look at the implementation cost, which I think is important.
We also look at the maintenance cost and, you know, what does it cost to implement a well-structured terminology or set of terminologies versus trying to maintain the gamish that we have got now. That is a problem for us.
Then the fourth cost we look at is the opportunity cost of having to move to some different standard in the future. For instance, if a vendor or some proprietary standard goes away or we can't afford to license it anymore, what is the cost of migrating our data, given that we are required by federal statute to retain most of our data for 75 years. So, we look at those four categories of costs; acquisition, implementation, maintenance and the opportunity cost of migrating.
DR. COHN: I think you have the last comment, Peter, and then we will be finishing up here.
DR. ELKIN: I, like Mike, believe that you can get your arms around this better if you divide it into practical examples of what the implementation costs might be. I might suggest that some of the more universal things within the implementation costs that one might look at if they were to perform a study might be the cost of adding colloquial terms to the terminology, cost for changes in the reference terminology and a cost of integrating the terminology into the medical record and the training associated with it.
DR. COHN: I think we are getting very close to 1 o'clock. Now we are going to adjourn in just a second.
My one observation in all of this -- obviously, we have talked a lot about cost, but recognizing that currently health care consumes about 11 percent of the gross domestic product and if current health care inflation continues by the end of the decade, we will be up somewhere around 17 percent. We just need to be aware in all of our discussions about cost that really the issue is costs are probably rounding errors on all of this. Really, the area that we need to be concerned about is the value proposition for anything that we are recommending and if indeed that is -- there is a strong value proposition, it might make everything else look sort of silly in comparison.
Clem, final comment, and then we will break.
MR. MC DONALD: I didn't want to bring this up, but I -- so maybe I shouldn't.
DR. COHN: I am hoping this is a comment and not a question for the panel.
MR. MC DONALD: Basically the -- this is a philosophy I have expressed before is that the challenge we have is that if we really want this standard to be workable, we want it to be required by everybody. I mean, that is we want everybody to use the same code. If we make everybody use the same code, then those who provide the code have a monopoly. So, we charge them -- we give them a monopoly, which is okay. But then we would expect the cost to be very important because we will have political kickback if we do that and in a capitalist and successfully capitalist society without letting there be kind of competing vendors.
When there is a competing vendor, the costs just all work out in a wash. We want to not have a competing vendor probably in the sense that we would like to have a common code or interlocking codes. So, that is the challenge of cost. If I am a vendor and I have heard this inventor say that I have to use this give code system and I have to use it and they can charge anything they want, I am going to be very nervous about that. In fact, I will probably politically object to it.
So, that is why I think we have to be sensitive to the cost in this domain.
DR. COHN: I am not in any way saying we don't need to be sensitive, but there is that other piece that we need to be aware of.
Okay. With that, we are way over our time. We will adjourn until 1:50 and come back. Thank you very much.
[Whereupon, at 12:57 p.m., the meeting was recessed, to reconvene at 1:50 p.m., the same afternoon, August 28, 2002.]
DR. COHN: Why don't we get started. Jim Campbell, I think you are on first.
DR. CAMPBELL: Mr. Chairman, ladies and gentlemen, thank you for the opportunity to speak today. Just a little bit about my own affiliation. I practice medicine at the University of Nebraska. I'm an editorial board member of SNOMED and also participate in HL7 and LOINC. I also vend terminology services to approximately 10 enterprises within Last Word Software. And all of those are affiliations of which I think you should be aware.
If we look back ten years, this is the anniversary that the Institute of Medicine basically painted their vision of what the computer-based patient record was all about. That vision rested upon a model which had a number of deliverables that clearly required coded or control terminology in order to create that functionality. Yet, at the time that they painted this vision, most of the coding systems that were available were primarily billing, administrative, and epidemiological systems.
Now, in the past 20 years or so there have been several coding systems that have grown to a large enough mass that we can consider them clinically comprehensive. There has certainly been a great deal of work done on messaging interoperability. And we have seen the emergence of reference terminologies and some of the technology that is associated with that.
What we propose to do today, I hope, is discuss the path whereby we achieve the Institute of Medicine vision, preferably by creating a scenario where cohesive and comprehensive clinical reference terminology can be available not to all us just to communicate between computers, but actually to share knowledge between computers. And I think you call this semantic interoperability in your document.
It has been discussed several times today, and we can bandy the numbers about, but there are a number of publications which basically document the substantial investments that have gone into reference terminology creation and development, and I won't go back and reiterate those.
The question is how can we go from the scenario that was described in your document, to something that -- by that I mean the listing the terminologies that were discussed in your document -- to creating something which can finally deliver the vision of the Institute of Medicine?
I would suggest to you that the path to that probably begins by looking not just at the number of codes we have available, but also at the architecture of how we employ them. And what I would like to suggest to you is that you consider adopting a slightly different model of how we should organize and maintain codes for the computer-based patient record.
In this graphic I have basically pictorialized a model, if you will, which is broken into three layers. As we go from the center to the outside we basically go from the clinical layer to the external layer, or the public and government, if you will.
The deliverables for the core layer are basically the deliverables of decision support that can be shared. Which means the core is a reference terminology that is brought together from resources that we have available today in work by American standards developers.
We know though, that reference terminologies cannot provide complete clinical coverage for computer-based patient record systems. There are many other special interests, departmental systems and so forth, that have to be included in the overarching clinical structure if it is going to be complete from a clinical standpoint.
And one good example is the participation of nurses in the clinical care enterprise. Clearly, many of their concepts have historically been poorly represented in reference terminology systems. And these concepts and their associated care processes must be brought out.
So the second layer in this model is basically that of modeled code sets or legacy term sets, or other systems that are necessary to the clinical function of the CPR, are modeled on a negotiated basis with a clinical reference core, within the construction of an information model.
An information model is basically an agreed upon set of definitions that take core reference concepts and model more complex or context rich concepts. One example that actually came up earlier this morning was the question of an order. An order may very well be modeled actually as an ordered set of a number of reference terminology codes. But the agreement upon what the basic structure of an order is would be an example of the modeling that would take the reference terminology into the broader arena of the entire clinical record.
The third layer here basically represents the administrative and governmental layer, where we have to interface with a variety of users who have important needs for the CPR data that are not primarily clinical. Now, let me discuss, if you will, these three layers just briefly.
The core convergence reference terminology that is basically a reference terminology in every sense of the word, but is designed to be comprehensive across all of what we need for multidisciplinary clinical care. Its primary editorial policies are clinical, which means that that is its goal, and that is how it is maintained and developed.
I would suggest that over time, it has to be edited in such ways that we are sure that it delivers knowledge. Therefore, it is edited based upon feedback from guideline organizations who are using the material actually to implement knowledge in running clinical systems.
And finally and preferably, it is maintained by a standards development organization with a hand off to clinical professional societies, who then take over what is increasingly sophisticated clinical content.
The features of the layer two set is that here we have modeled codes which basically integrate important clinical terminology. These terminologies generally were never designed to be comprehensive. For example, nursing term sets were never designed to be an entire medical record, but nonetheless, they are an important part of the CPR.
So this layer, if you will, serves departmental, special purpose, messaging systems, professional and perhaps interface terminologies which make the CPR easier to use. Everything within this layer is basically constructed using the reference core, but it is modeled into the necessary context and behavior that is required based upon the meaning values if you will, from the original legacy owners. Needless to say, these two layers have to be maintained in negotiation. There has to be a dialogue between the reference terminology and between the modeled code sets in order for the whole thing to be successful.
Layer three is basically code sets that are required for administration, finances, billing, epidemiology, et cetera. These are fundamentally not patient care oriented, so therefore, they follow different editing rules, which are basically the rules that are promulgated by the organizations that need that. That is, the purposes of ICD-9-CM are not precisely the purposes of clinical care.
So the reference agency which manages these code sets basically controls their content. And I would suggest to you that relative to what several people suggested today, this layer probably is maintained in a different way, and held to different standards than the internal clinical layers, which really need to follow basic concepts of how a reference terminology should be maintained.
Now, the question is why go to all this trouble of creating this model? What I would like to do is basically talk about how it would help us to organization of the priorities for what HIPAA should do. Secondly, I would like to identify the position of individual vocabulary elements within this model. And then thirdly, talk about then should the performance criteria change within each layer of the model for how we select what coding systems to use.
Speaking from my own personal point of view, I would like to suggest that there are three major priorities that I would pursue if I were writing the checks. The first is I think it's critical that we set up a collaborative strategy so that we can define a core reference terminology which can serve clinical medicine. And as I will explain in a minute, that is probably a combination of several existing coding systems, and I'll talk about that a little bit more.
Secondly, I would consider that the most important thing to the business model and the vendor community is that there be solid mapping. And by that I mean it probably has to be knowledge-based mapping from the reference core to the third layer, because this is going to be important to the ability for vendors to actually install and maintain computer systems. If the clinical data does not yield the necessary administrative and billing data in a relatively seamless way, it is not going to be acceptable in the American marketplace.
And thirdly, and I toyed with the notion of whether this should be second or third, I think there are some important issues within the issue of clinical content coverage, and I think they rest within this layer two. I disagree with some of the previous speakers in that I personally think that it's important to converge nursing terminology with the rest of clinical care, so that we really have a multidisciplinary clinical care model that is universal.
In addition, because of the some of the efforts that are ongoing right now, started by the Institute of Medicine projects on error reduction, I also think the drug information sets, that is Multum, First Data Bank, and the others should also be given priority for early instantiation into the model layer. And from my personal point of view, those are the priorities that I would set in terms of getting us started as quickly as possible, with a reference terminological scheme that could actually deliver on our entire vision.
If we think a little bit about what codes should be considered in these three layers, Table 1 I believe of your handout basically is a reorganization of your list of codes around my concepts. And in the convergent reference terminology that is the core of this whole model, I think that SNOMED CT has a very critical place to play.
I think something that has gone unrecognized in recent years is that when SNOMED RT was released, basically LOINC and SNOMED at that point converged, at least in the laboratory area. And I think that that convergence should be fostered, so that SNOMED CT, LOINC, and what I found out is actually called the Rx Norm project of the National Library of Medicine should be considered as probably the most the logical candidates for making a core reference terminology happen, and happen in a short time frame.
I mentioned the clinical dirge because of the fact that in the past at least, SNOMED has never made an editorial commitment to maintain a clinical drug system. Now, there are some changes there that are happening, because of negotiation with the National Health Service, and their interest in maintaining what they call the UK CPRS, which is their clinical project resource system. And they are actually planning to maintain a national clinical formulary for UK. So perhaps that should be considered as a part of the strategy in this core reference terminology.
Within the second layer, I think most of these choices are fairly obvious, except that I would add that I pulled in the ICNP codes for nursing, because talking with nursing colleagues, there are quite a number of people who have referenced the importance of that in terms of convergence.
And I have also mentioned under medicine, ICBO and ICPC. ICBO basically is subsumed within SNOMED, so it should not represent much of a problem. But the primary care area I think is poorly represented in many systems. And ICPC is probably mentioned most often in reference to expanded codes for primary care.
I would add that I don't know much about MedDRA, and I don't have much to say about it, so I left it off the list, but that is primarily out of ignorance.
I made no changes to the mapped administrative and financial classifications in layer three, and I think all of these are fairly obvious.
Now, if we think about this three layered model, and the suggestions I have made as to what codes should go into each layer, I think there are a few observations we can make about criteria for code selection or terminology selection in each layer. First of all, as far as general criteria are concerned, I agree with everybody that I think it would be great if this were free, but many times free just don't cut it in terms of function.
So I would at least balance that statement with the notion that core reference terminology developers, that is, the people who are putting together the heart of this system must have a business model which organizes and funds the timely evolution, distribution, and perpetual maintenance of the terminology. And I would add that as a new criterion.
Secondly, considering clinical scope and organization, the question obvious of completeness only makes sense if you look at it basically at two layers. Completeness from the administrative sense is at the third layer. Completeness in the clinical sense is in the inner two layers, where we have basically the reference terminology and its cooperating model systems.
I would suggest to you that if we approach it that way, then core reference terminology developers must cooperate with their negotiated demands, which means I think that the most pragmatic thing is that we direct SNOMED, LOINC, and the Clinical Drugs Project to cooperate, decide where they are going to develop, and how they will interact, and make sure that they do it in an orderly way together, because that is the fastest way to get to our goal.
So they should cooperate within their negotiated domains to produce complete clinical concept definitions, and a cohesive semantic network defining all central domains of the clinical practice record.
Secondly, considering the interaction between the core layer and the second layer, I would suggest that those core reference terminology developers must have cooperative agreements with layer two developers so that content and editorial evolution is orderly and cohesive.
All of this basically implies that we have an overarching information model for what we are doing within the inner two layers. And I would suggest to you respectfully that the committee consider as an added item to their work task, that a reference information for definition of complex and content-laden concepts will be developed, and a standards development organization should be identified to maintain this model, because that is necessary to the proper interaction between the inner two clinical layers.
Let's think a little bit about concept orientation. Must of what the committee has down really addresses more the issues of the reference terminologies. And I would suggest to you that many of those criteria probably should not or cannot be applied to layer three, because we really have no control over those terminologies.
But I do think that we do need to give some consideration to what relationships are supported within the core, because those relationships ultimately become part of the knowledge base which is used to deliver clinical decision support. Therefore, we must demand that reference terminology relationships within the core should be sufficient in definition and scope to support clinical guideline implementation.
Now, at the very least it's a no brainer that they have to have a good subsumption hierarchy. And they probably need a modest number of additional relationships. We probably don't need the most complicated models in order to be successful with the decision support we could implement.
Within this model, obviously there is an understanding between the layers as to what provides in terms of role. I deleted one item. I would mention that in all my previous slides the items in gray were not deleted. They were just put into the background for emphasis. But I did actually delete this one, Maps to a Broader Clinical Reference Terminology. And instead, I basically identified what my assumptions are for each of these three layers.
First of all, core terminologies provide domain content to support complete clinical reference terminology. Secondly, layer two terminologies model, define, and enhance important legacy and departmental classifications and terminologies. And then thirdly, these two map to layer three terminologies to support reimbursement and statistical classifications. And that is a fairly loose definition of what the interaction between those three layers should be.
About maintenance practices, I mentioned a little bit earlier I think that I would agree entirely with previous speakers that maintenance releases must be timely, but it depends entirely on what portion of the terminology we are speaking about. And they must have a sound business model.
I would suggest also that core reference terminology developers should collaborate to have domain content reviewed and regularly edited by clinical professional societies. No matter how good an SDO is, eventually if we are talking about complex clinical data, it has got to move more into the experts who actually practice in those fields, and are the people developing the guidelines.
And secondly, I would say the core reference terminologies will be maintained by an open editorial process in conjunction with professional societies, preferably within an ANSI accredited standards development organization.
Finally, I would add one consideration. In the list of terminologies that I gave you, I would reference three which are actually international in scope. I think that it is desirable, but not necessary that we consider international standards in our negotiations. And I would suggest that proper and useful relationships with international standards such as is happening in SNOMED CT right now is a factor which should be considered.
Thank you.
DR. COHN: Jim, thank you very much.
Margaret Haber from the National Cancer Institute.
MS. HABER: Good afternoon. On behalf of myself and my colleagues at the NCI, I thank the committee for the opportunity to provide comments. I am Margaret Haber, technical information specialist with the Division of Cancer Information Products and Systems, Office of Communications, of the National Cancer Institute. I serve as the coordinator and project officer for effort related to both division and institute level vocabulary development, including the disease and drug terminology for NCI Thesaurus, and mapping between vocabularies for multiple systems at NCI.
And to provide the committee with a bit more background and context, let me tell you that CIPS Division is responsible for the production of Physician Data Query, which is NCI's database of evidence-based review summaries on cancer treatments, screening, prevention, genetics, and supportive care. The PDQ clinical trials database currently contains some 1,800 open and 12,000 closed cancer clinical trials. The division maintains cancer.gov, which is the portal Web site to NCI, and provides primary content to the NCI Cancer Information Service.
As providers of information at the institute level, we also work cooperative with the NCI Center for Bioinformatics on NCI Thesaurus and NCI Metathesaurus, an institute level vocabulary and a meta vocabulary environment which are core components of the Center's Enterprise Vocabulary Services.
The issue of specifications and standards for PMRI and related terminologies of one of acute concern to the NCI, as we are both a user and a provider of vocabularies related to our diverse missions. The NCI represents a microcosm of the broader medical community on issues of standards for interoperability such as vocabulary. We face many challenges, among them diverse organizations and goals.
There is an historical disconnect of data collection priorities and methods, with information housed in discrete systems, and coded using different vocabularies for portfolio management, clinical care, research, public and provider information, and epidemiology. Furthermore, there can be significant differences in the meanings attached to a particular term in the vocabularies of these various communities.
We also have an inheritance of legacy systems. Achieving connectivity between established mission critical systems involves complex issues of data conversion, storage, and retrieval, especially for retrospective research. Barriers include not only disparate electronic systems, but at times the lack of an electronic system entirely.
We have changing health information models. Health care and cancer care is shifting from an emphasis on treatment, to one of the prevention. Even more fundamental is the rapid transformation of disease models from traditional to the new genetic and molecular classifications.
Finally, there is the pace of change in science, technology, and methods. The vocabulary content and structure must quickly reflect these advances in order for them to remain useful, which still permitting the identification and retrieval of artifacts tagged and coded using earlier systems and vocabulary versions.
We have approached these issues at NCI with Enterprise level initiatives to integrate both intramural and extramural data resource, particularly for clinical trials, in collaboration with outside partners such as the clinical trials cooperative groups. The Center for Bioinformatics is developing tools and technologies to support these efforts, including a cancer data standards repository to standard meta data for clinical cancer research.
The Center is also collaborating with CIPS OC to develop NCI Thesaurus, which is a controlled reference terminology to sort NCI's vocabulary needs from basic and translational research, to clinical care. The effort was spurred by the realization that linking related concepts in the fields of population, genetics, developmental therapies, and disease was essential to our mission.
Cancer information encompasses a broad spectrum of medical knowledge, as cancer and its treatment potentially impact all aspects of human health. The rapid evolution of information models in cancer mirrors the challenge of addressing knowledge systems at the broader level of standardized PMRI.
For the NCI, this fundamental and ongoing transformation means that any proposed information model not incorporating the assumption of frequent change will be destined to failure. These rapid changes in both information models and technological capabilities mean that standards development must anticipate the future evolution of PMRI.
More specifically, vocabulary standards must be able to insure the adaptability of a terminology or information model to incorporate intellectual content changes. The capability, commitment, and funding to support frequent regular cycles, and the flexibility of a terminology structure to map readily to other major component vocabularies. These are perhaps even more important indicators of the ultimate success of a standard vocabulary than simply an examination of their current contents.
HIPAA requires portability, accessibility, and security of data, and hence, requires standardized interchange of information across systems. Stable, reliable, and consistent meanings of vocabularies and codes is a fundamental component of this requirement. Integrated coding vocabularies are also essentially to realizing the goal of building and expanding the National Health Information Infrastructure, public, private, cooperative, and federal eHealth, and other related efforts to provide the structures and information resources for personal, provider, and public health data needs.
While I will refrain from comment on the individual vocabularies, in examining those being considered as standards, it would be instructive to see a table showing coverage of the various vocabulary and code sets by content domain, as several of the specified vocabularies have crossover content, for example, the ICDs, LOINC, and SNOMED.
Providers should be asked to indicate depth and breadth of coverage, as well as other quality indicators for each domain. Some vocabularies necessary to provide coverage in special domain areas, and we have noted several times ICD-03 for oncology reporting as an example, may have been omitted. An illustrative, and this is illustrative only, by axial chart structure as shown here, might better reflect the content coverage of the specified products.
The PMRI selection process should accord priority to terminology development efforts that are linked to and integrated with related clinical document architecture, format, and messaging standards such as the HL7 vocabulary standards development process. Representatives from the major divisions of NCI will become more active participants in the standards activities of HL7 as we feel that an inclusive, collaborative process offers the best opportunity to lever the power of multiple developers.
Cooperative endeavors at the federal level such as NLM's Rx Norm and the VA's National Drug File Reference Terminology, which is being developed in cooperation with FDA, NLM, and most recently NCI may also serve as models for further collaborations.
The criteria outlined by the committee for PMRI terminologies cover the main principles for sound practice in the creation and maintenance of medical vocabularies, and would generally apply to all sources. Under the category of General Criterion, I would add that vocabulary sources should have explicit, defined, and regularly processes for both technical and content quality review and assurance.
And I would emphasize again under maintenance, the necessity of a consistent, reliable, rapid update process sensitive to the changing needs of the national health community. Content control and regular review by domain experts is essentially for both usability and validity, and should be a hallmark of every specialized vocabulary, or vocabulary domain.
PMRI terminology developers should be encouraged, but not necessarily required to be accredited as ANSI standard developers. Market acceptance of well principled terminologies can create de facto standards. However, standards that purport to serve the needs of a diverse community ought to be open to community involvement.
Finally, PMRI terminologies cannot be examined without looking also at the tools available to create and maintain them, and the integrity of the mappings between them. In fact, accurate mapping is a task often as complex, and as much an intellectual product as the vocabulary itself.
The ownership, maintenance, and integrity of mappings between all major required recording vocabularies for PMRI should be as explicit as the requirements for the maintenance of the terminologies themselves. The relative lack of sophisticated tools for this task presents another barrier to integration.
The challenges encountered by the NCI in creating a more unified terminology for oncology reflect many of the same complexities involved in terminology standards for PMRI. And we thank the committee for its good work in tackling this process, and we hope together towards shared solutions.
Thank you.
DR. COHN: And we thank you very much.
Marc Overhage, you're on next.
DR. OVERHAGE: My name is Dr. J. Marc Overhage. I'm an investigator at the Regenstrief Institute for Health Care, and a faculty member at the Indiana University School of Medicine. The experience I will draw in my testimony is really drawn from our last ten years of efforts at dealing with a microcosm of the tasks that the committee is charged with trying to undertake on a much larger scale, and that is building a regional electronic medical records system.
I'm going to try to follow the questions that the committee posed in their document, and start out by talking about the first, the categorizations of codes that were proposed in the committee's Scope of PMRI Terminology Table, from the committee's report to the secretary in August 2000. The problem that I have with this classification is simply that I find it difficult to work with in terms of segregating out the questions that I need to ask in order to appropriately analyze these domains.
And I find it much more useful to take more of an object-oriented approach, or an entity approach on whether these correspond to specific terminologies individually or portions of larger terminologies. I find it much more useful to think about things like units, orders, clinical observations or results, medications, and allergies than I do aggregated codes or nursing codes, or some of the others that were in the table that the committee had published.
In addition to that, I believe that this approach keeps the concepts more closely aligned. It is a common problem that one encountered of seeing the same concept labeled differently in different terminologies, when in fact it is truly the same thing. Adverse drug events being a good example of where we tend to try to create some new terminology for that, when in fact it's the same old clinical events we've been dealing with for the last 25 years. And so I think this approach keeps it more closely tied together.
And thirdly, that it promotes reuse of the data. Whatever we are going to do with these terminologies, we have to pull together both the clinical processes, and the other uses of the data that we hope to put to it. And whether that happens through mappings or through other approaches, it is critical that the concepts be carried through from the clinical processes, forward to the other uses in a faithful way.
A second point is that when we talk about terminologies, we are often not talking about one thing. For a particular domain, we actually need typically at least three levels or subdomains of terminologies, or conceptually at least.
First are the questions or variables. These would correspond to things like glucose concentrations measured in serum, or a Glasgow coma score assessed by an emergency room physician, or a discharge diagnosis encoded by a hospital discharge clerk.
Second are the answers or the concepts, the results of those questions, or answers to those questions. These are sometimes numeric, things like the value of the glucose concentration. Or they might be free text, portions of a document, for example. But often we would like those to be coded as well; names of organisms for example, or simply positive and negative.
And the third subdomain that we like to think about are packages or batteries of codes. Things that we bundle together for reasons of convenience, such as electrolytes, the test elements that belong to study members 1325, or vital signs.
I'm going to drill down in the next few slides a bit into the laboratory domain, and talk first about orders. So these are collections or categories of things. And these of course are from the laboratory tests are radiologic tests. And at the second level they are simply the results, the serum sodium or the serum glucose that is measured. And each of those may have values such as the name of the organism, Escherichia coli or positive, as I said before.
When the committee asked to comment a bit on the different criteria that were proposed for looking at these different terminologies, I wanted to reinforce a couple of them that I think are critical. First, that it's relatively inexpensive to acquire and to implement. And there has been a lot of discussion about that at the testimony today, but it is a critical barrier.
Perhaps as important is the issue of acceptance in the marketplace. Free don't necessarily insure quality, it doesn't insure value. Acceptance and use is a tremendous barometer of how good or useful a particular terminology might turn out to be.
There are, I think, some additional criteria that should be considered. First, it is important that these terminologies reflect clinical realities, rather than being conceptually pure. And what I mean by that is you would like to avoid the collision that occurs if you take a very purist approach when you meet up with reality such as combination drugs, and things of that nature.
Second, the codes should be context-free, should not contain any meaning in themselves, and that has been said by several other presenters.
And then a few cross-terminology cutting issues. First, that the compositional strategies need to be consistent across the terminologies that are adopted. It's too confusing to have different ways to combine clinical concepts. And also that there be consistency, with an overall information model such as the HL7 RIM or Reference Information Model.
As the committee considers which areas to focus on first, and one of the reasons for subcategorizing I think is to allow us to focus, and not have to cover the whole of our problem space at once. And one of the ways to prioritize these are to first look at the quantity of electronically available data. What is out there that we can get at today and take advantage of?
Second is the relative value of that particular domain or type of data on a global basis. Obviously, for an individual patient or an individual need, certain data is critical, but there are certain things that are valuable across many domains and many uses. And finally, the availability of "good" terminologies, good enough places to start.
Some obvious targets using those criteria are things like laboratory results, which already reside largely in electronic databases in most of our institutes. They are widely applicable for patient care and other purposes, and likewise, there are some potential candidate terminologies such as LOINC.
LOINC is the Logical Object Identifier Numerical Coding System, which was designed to provide a universal identifier for observations, so that information about observations from different sources can be combined in one electronic medical record system or research management database. Said differently, it's to provide a universal ID for the HL7 OBX field 3, at least for the domains that it covers.
LOINC does try to provide all three subdomains I talked about before. It tries to deal primarily with batteries and questions, and not with the answers. So questions, as I said before, variables or observations would be synonyms for that, such as serum glucose or blood culture, or batteries such as the SF36 set of questions for patient status assessment, or a comprehensive metabolic panel, a collection of laboratory tests done to gain an assessment of the patient's overall metabolic state.
LOINC started out in 1995, with only 4,000 entries, but this year there will be over 31,000 entries. And on the slides it lists various resources for discussion, and for obtaining not only the codes and files themselves, but also documentation and tools for mapping local codes to LOINC.
And as I said before, one of the measures of the usability and success of a terminology is its adoption and use. And I'm going to briefly review some of the ways that LOINC has succeeded. First, government and various other organizations have adopted it, many of them listed here on this slide.
Large pharmaceutical organizations and consortia of those organizations have seen LOINC as an appropriate tool, and in fact CDISC, which is a collaboration of large pharmaceutical groups for reporting clinical trials data have incorporated LOINC as the key standard.
Large laboratories, reference laboratories in particular have embraced LOINC not only as a tool for sharing data with their clients, but for resolving their internal mapping problems as they purchase and consolidate services from other regional labs that they have purchased.
Large health care systems such as Kaiser, Partners of Boston, and Columbia Presbyterian, large managed care organizations, which again, have to aggregate data from many sources. And I think importantly, there has been success with instrument vendors and test developers. In other words, labeling at the source as the tests are defined and developed.
And this has not just been a United States success, but been international as well. And LOINC has been translated into multiple languages, and adopted as the standard for a variety of initiatives throughout the world.
In closing, I would like to leave a few thoughts. First, that it's important to keep the terminology domains conceptually pure. In other words, to avoid this problem of trying to make all things to all people.
Second, to remember that we have to keep the clinical processes connected. We don't really need or want to create new concepts where they are the same. And mapping is maybe a partial answer, but always a risky and difficult to maintain answer. And one of the ways to think about doing that is to differentiate the concepts and the structures. For example, an adverse drug event as the occurrence of some clinical finding associated with the drug. It's not something new and different. So it's a relationship rather than a concept in and of itself.
And finally, that LOINC satisfies many of the criteria, at least for the laboratory domain, fairly well.
I thank the committee for their attention, and look forward to your questions.
Thank you.
DR. COHN: Thank you.
Michael Beebe from the American Medical Association.
MR. BEEBE: Good afternoon. It's good to be back before the subcommittee. I'm Michael Beebe, director of CPT Editorial and Information Services for the American Medical Association. I think this is my fourth presentation to the subcommittee in four meetings, so it might be eligible for the Cal Ripken award or something.
My statement today will summarize the views of the AMA on patient medical record information terminology. The following comments will address the questions that have been asked to be discussed by the subcommittee, as well as other issues of concern to the AMA.
The AMA believes that a patient's medical record should include sufficient information for physicians and other appropriate health care professionals to assess previous treatment to insure continuity of care, to decide upon further treatments and clinical activities, and to avoid unnecessary or inappropriate tests or therapy.
The medical record is the primary source of information for a patient's overall health care, meeting all clinical, legal, and administrative requirements. In essence, PMRI is medical and health care data about an individual, including facts, observations, interpretations, plans, actions, and outcomes.
This description should apply to either paper or electronic formats of patient medical record information. Moreover, the strictest protections of patient privacy must apply to such information. Comparable and accurate PMRI will assist in realizing the clinical utility of such information, and also enhance the value of such information for clinical research and epidemiological purposes.
At the same time, efforts to enhance comparability and computer operability must not detract from the fundamental clinical purpose of such information, as outlined above, which will focus first and foremost on the needs of patients, their physicians, and other health care professionals in the institutions and facilities in which they receive their care.
In addition, the AMA believes that the terminology supporting PMRI should be comprehensive, and include all the clinical terms used by all members of the health care team involved in record writing. Despite the need for sufficient terminology breadth to accomplish all the varied purposes of PMRI, the AMA believes that the terminology selected must be limited to discrete and non-overlapping functional areas. That is, only one terminology per area.
The AMA is also concerned about the accurate and consistent implementation of terminologies. Standard implementation guidelines for terminologies are essential for uniform national application of the code sets. If health plans and providers are permitted to implement and interpret medical data code sets as they see fit, the purpose of administrative simplification will not be achieved.
In addition, the AMA recognizes the limitations on the human element of code application, and is concerned about the needs for education on all the code sets, or the development of computerized tools to achieve semi-automation in applying the codes. The AMA believes that terminology supporting PMRI should be able to be cross-referenced with other terminology currently in use, and those in the future.
Two years ago the AMA commissioned a study to develop a report identifying a comprehensive list of core clinical data elements for electronic medical record systems. The study was conducted by Medical Systems Development, a firm specializing in market analysis of electronic medical records and practice management systems, and was conducted for the AMA's Council on Medical Service, and was eventually adopted by the AMA's House of Delegates.
The data elements identified were derived from a large number of diverse resources, including uniform data sets, accrediting and licensing agency requirements, industry standards, selected electronic medical records literature, and electronic medical records vendor system specifications.
The AMA believes that the components of an electronic medical record that are of most concern to practicing physicians are in the area of core clinical data elements. Moreover, this is an area where practice management software vendors continue to fall short in the development of their products.
If you read my written testimony, it struck me that many of the core clinical data elements are similar to the object-oriented model put forward by Dr. Overhage. Elements such as: patient identification; demographic data; special patient health conditions; allergies; immunizations; health promotion; disease prevention; past medical history; past family social history; laboratory tests and orders; diagnoses; therapeutic service procedures; orders results; medications prescribed and their results.
The AMA believes that the committee should prioritize the PMRI terminologies based on current use, practical applications, acceptance in the marketplace, as well as benefits of the system. Focus on the big bang or the immediate results, as someone mentioned earlier this morning, to get people's attention.
The AMA believes that the criteria identified are acceptable towards selecting appropriate PMRI terminologies, however, it should be divided into essential criteria and desirable criteria, as well as consideration given to the different domains.
We see that the four criteria derived from the PMRI guidelines should also apply to PMRI terminologies. These four criteria for the guidelines include: market acceptance; interoperability; comparability of data; as well as the ability to support data quality, accountability, and integrity.
In addition, as the committee stated, market acceptance is by far the most important, because identified standards that are implementable, cost justified, and flexible enough to meet the needs of most relevant marketplaces. For example, the following demonstrates that CPT procedure codes meet all of the above mentioned criteria -- market acceptance, interoperability, comparability of data, as well as the ability to support data quality, accountability, and integrity.
The CPT code set has been maintained and updated by the AMA since 1966, with yearly updates since 1977. A large number of products including CPT have been licensed involving over 350 different vendors. Physicians and many other health care professionals use CPT almost exclusively for reporting all health care claims.
One hundred percent of health care institutions use CPT. All health care third party payers that process medical claims use CPT, as well as CMS, the Department of Justice, the Department of Defense, the Indian Health Service, 42 state government agencies, and Puerto Rico.
CPT codes have been used by the Medicare Program since 1983, and have been associated with the RBRBS since 1992. Additionally, CPT is used internationally in South Africa, Mexico, England, New Zealand, Hong Kong, Belgium, Canada, Italy, Latvia, and Venezuela, and we currently working with the governments of Japan and Israel for their translation and incorporation of CPT.
Also, as I mentioned to you about a year ago, CPT is working on working on achieving greater interoperability by developing a formal data model using description logic and subsumption hierarchies, as has been mentioned so often today.
The AMA believes that all coding systems adopted as standards should have an open updating process, and any interested party should be able to submit proposals for additions and modifications. In addition, the responsible panel or committee of experts that are representative of a broad cross-section of the relevant stakeholders should maintain the terminology.
The AMA does not believe it is necessary for PMRI terminology developers to be ANSI accredited, however, the organization maintaining the code set should insure continuity and efficient updating of the standard over time. We believe that PMRI terminology maintainers should meet all the guiding principles that were expected of the current maintainers of the selected HIPAA standards.
These standards include:
to improve the efficiency and effectiveness of the health care system by leading to cost reductions, or in this case quality improvements;
meet the needs of the health data standard user community, particularly health care providers, health plans, health care clearinghouses;
be consistent and uniform; have low additional development and implementation costs relative to the benefits of using the standard;
be supported by an ANSI accredited standards setting organization or other public or private organization;
have timely development, testing, implementation, and updating procedures to achieve administrative simplifications faster;
be technologically independent of computer platforms;
be precise, unambiguous, but as simple as possible;
keep data collection and paperwork burdens as low as is feasible;
and incorporate flexibility to adapt more easily to changes in the health care infrastructure.
A recent study that was commissioned by the AMA on HIPAA standards found that 7 out of 10 physicians indicated that they and their staff need more information about transaction standards, privacy and security standards. Furthermore, 72 percent of responding physicians do not believe HIPAA will save their practice money in the long run, because of billing and other processes being simplified.
Although the AMA has long held that increased use of electronic financial and administrative transactions could increase the efficiency of physicians' practices, as well as the health care system overall, the results of our survey indicate that physicians are frustrated with the impending HIPAA regulations.
The development of PMRI standards must build on this lesson by focusing on market acceptance and clinical needs. The AMA understand that the responsibilities of the NCVHS are to evaluate and recommend patient medical record information standards and applicable terminology. However, it is important to note that NCVHS responsibilities on this issue are fundamentally different for HIPAA administrative transactions. There is no federal legislation requiring implementation of patient medical record information standards, or the code sets that would apply to such standards.
We all need to keep in mind that if used uniformly, PMRI standards must first and foremost meet the needs of the clinicians where the care is being provided. Standardized terminology could be extremely beneficial to the primary users, which would be the physicians providing medical care to patients. However, other uses such as research and fraud detection would be secondary.
Therefore, the HIPAA standards for transactions in privacy and security should first be implemented, and demonstrated to be effective before PMRI standards are established.
Thank you very much for the opportunity to present the views of the AMA, and I would be happy to answer any questions.
DR. COHN: Michael, thank you very much. Questions?
DR. AUGUSTINE: Dr. Campbell, I have a question for you. Earlier testimony today talked about as opposed to having what you called layer one, the reference terminology, just making sure that the existing terminology was more interoperable. And that having a core reference terminology would be kind of prohibitive. What are your thoughts on those comments that were made earlier today?
DR. CAMPBELL: I'm not sure if I understood you. The core reference is to be a reference terminology that would support all of the basic types. I think there were a couple of lists of them up earlier from previous presentations, diagnoses, assessments, findings, symptoms, procedures, et cetera, basic types of clinical care. And then the second layer would basically bring in the departmental or special needs.
Now, am I misunderstanding your question?
DR. AUGUSTINE: What I was believing was said earlier today was that rather than everything being built off the core reference terminology, building up or strengthening the interoperability, or the links between each of these other terminology sets that are shown I guess in layer two and in layer three, as opposed to using the core reference terminology.
DR. CAMPBELL: I probably wasn't clear enough. Layer two is meant to converge with the core. But understand that these will be concepts that will end up maybe having a fairly complex model. Like an order might have six or eight different attributes that are necessary to completely specify a unique order.
But one of those, for example, would probably be the procedure code, or a result code, which would specify the basic action that is intended, but under the other elements about when it starts, and when it stops, and how many times to do it, and things like that. So that would be the information model that would define how the reference core relates to the definition of the order in the second layer. But the entire inner two layers would be consistent, and internally they would share many, many attributes.
DR. AUGUSTINE: Do you find it to be necessary to have that layer one, that core to have a good PMRI?
DR. CAMPBELL: Well, I think that pragmatically we are at a point in American SDO development that we've got a critical mass of that developed. I think it would be imprudent to abandon that investment. And I think we should encourage moving forward with it.
DR. AUGUSTINE: Thank you very much. That was a wonderful presentation.
MR. BLAIR: Dr. Campbell and Dr. Overhage, you both wound up coming up with better ways of representing the scope of what we have to deal with. And to be honest with you, I was really kind of excited by both of your presentations. Obviously, we are going to need to look at, the members of the committee, to try to see how we go forward.
So I would like to ask each of you if as you heard each other's presentation, did you look at each other's presentations and wind up saying well, there are conflicts and compatibilities. These are mutually exclusive. Or did you wind up looking at this and saying, well, we could have Jim Campbell's layered model as one dimension, and maybe it's possible to have a second dimension which could complement that in terms of Marc's model?
And since you both know so much more about this area than I do, would you please comment on each other's visions or perspectives, and tell us if you see ways that they could maybe complement each other?
DR. OVERHAGE: Other than Jim being more artistic than I am, which goes without saying, I think that they can be very complementary. I tend to be a bit of a lumper when it comes to thinking about problems. And when I lump, sometimes that ends up decomposing the problem. So to me, it's challenging enough to think about this whole domain, and I've got to break it down.
Jim has in his core model, in the inner layer of his model, the world. And he can fit that in his head. I have trouble with that, and I have to think about breaking that down into some different domains that we can work through individually, and ask the question where are we today? What are the migration issues? And so on.
Because I think they are different by those domains. Drugs for example, today are almost always represented in NDC codes. If you track back far enough, that may or may not help you. But they are almost always there, and that is point A, or your starting point for that.
Laboratory results, on the other hand, every laboratory system installed has different codes, it seems like. There are a few commonalities, but it is all over the map, so you have different starting points. I have to decompose it to think about it.
So my view is they are not inconsistent. It's just a matter of when you come to looking at that layer one, or inner layer in Jim's model, it helps me to break them down into categories that I can sort through and categorize and analyze.
DR. CAMPBELL: I don't think that Marc and I differed in basic ways. I detected in his presentation, for example, flavors of editorial perception that grow out of the HL7 RIM. And that's a perfectly legitimate way to look at how the information system should be structured.
I would mention that relative to the information model I referenced, I think HL7 RIM would have to change in that right now the HL7 RIM is designed basically to test if you will, or to determine the appropriateness of the construction of HL7 message packages.
And I would suggest that the information model that I was talking about has to occur in negotiation with the standards developers, which it's not right now, and focus on the development of this broader set of definitions of a wide variety of constructions that HL7 really hasn't had much interest in.
So that's not to say that HL7 wouldn't be a logical organization for that, but it's a slightly different mission than the one they have been pursuing, because they have been responsible for a great deal of message interoperability, but they haven't been looking at a lot of semantic interoperability, which I would say is probably the biggest difference between Marc's talk and mine, in that we were sort of talking at those two different levels.
And that doesn't mean that one or the other is better, but I personally think that we need to be heading towards the semantic interoperability if we want to achieve intelligent clinical information systems.
MR. BLAIR: Are there comments from the other folks? I focused in on Dr. Campbell and Dr. Overhage, but I didn't want to prevent anybody else from making a comment.
MS. HABER: I would just add that in fact HL7 has extended now beyond simply messaging. They are looking at comprehensive both vocabulary building, clinical document architecture efforts to collaborate on clinical trials information. So in fact, they do represent a place to look for integrated vocabulary concern and development.
DR. MC DONALD: There has been discussion about the different contracts. And would like to clarify a little bit on HL7. I don't know all that is going on there either, but I don't think it's true to say that they aren't interested in vocabulary. They are very interested in vocabulary, but that's the remaining part that leaves things undefined.
I think if I could argue on Marc's side, we live next to each other in offices that are without doors. So it's not an accident that I may think that he had a good idea there.
But I think that the point about considering vocabularies in terms of a particular message structure is really a very strong idea, because it keeps you from wandering out into spaces that don't exist, or no one is caring about right now. If no one is sending the data, that's what HIPAA sort of was talking about in terms of exchange of data. We can make up theoretic worlds that may actually be harder to work into the real world.
That's not to say that Jim's model wasn't also equally a good idea. I wasn't really disagreeing with his model per se, which is to emphasize the idea that if you are dealing with things that people are really doing, it keeps you honest, and you can test them and see if they really work.
DR. CAMPBELL: And to emphasize that difference, I would reference a project we've got going right now with IBX, where we are trying to create an environment where we can transport guidelines from one institution to another, and one computer system to another. This is what we call semantic interoperability, and it requires these features. And we are trying to do that today.
DR. MC DONALD: I'm not disagreeing with the theory of semantic interoperability. I think that's exactly what people say when they say we've got these messages. We need standards codes in them. At least, that's how I've thought of it. I just it's not a bad idea to come back to a model and say I've got something to fit in this field, and does this stuff really work there, where it's really going across in real life. It's a good way to test your ideas to make sure you're not off in outer space, and I don't think that you are.
DR. CAMPBELL: Let's remember, the dumb codes, once they get there, have to have a definition.
DR. MC DONALD: I'm for it. I mean I'm not disagreeing.
DR. COHN: I actually want to ask a question or two, and start with Jim, and then go to Marc. I will apologize. I'm going back a couple of steps, just sort of dumbing it down a little bit.
Jim, just to make sure I understand your level two here, and I'm having a little hard time trying to figure this one out, because it seems to be sort of a heterogeneous grouping of code sets and data sets. Maybe they are really part of the information model. Can you help me with this one a little bit? Are they meant to be that heterogeneous?
DR. CAMPBELL: Well, pragmatically -- actually, Clem is the one who insists on this most often, in that the computer-based patient record has far more many types of things in it than we sometimes are willing to account. And the question is how to bring those things together in some sort of a model that makes them unified in some way, because they share many elements.
You know the thing you order, and the thing that results, there is a relationship between those things conceptually. That's something that if a computer information system could know, for example, order sets could become customized, problem-oriented data displays.
So the difference between the second and third layer of modeling versus mapping -- was I unclear on that? Because the idea is the second layer, when you are done with the process, you create the information model, and the various terminologies cooperate, you would end up with a modeled environment which is entirely consistent throughout the clinical layer. And yes, it does include a variety of funny neighbors.
DR. COHN: Yes, I understood the model part. I just couldn't figure out the fact that you seemed to have a lot of other types of elements in there.
DR. CAMPBELL: To give you one example related to medicine, right now we ended up as a middleware vendor for interface terminology for other IBX sites who are using SNOMED. Because what we do is we maintain entrance terminology so that they can do physician problem list recording. And we are simply providing that for them by creating pre-coordinated concepts.
It is not SNOMED's goal to try and create every concept every known to man. That's what compositional environments are all about. Which means that the vendors or the sites then end up doing some of that stuff.
DR. COHN: I have a different question, but did you have a follow-on question?
DR. MC DONALD: No.
DR. COHN: Marc, I had another sort of dumb down question for you about LOINC. I was sort of scratching my head a little bit now. Of course I know that there is a clinical LOINC and a lab LOINC. I knew that you were not in any way referencing in your remarks, clinical LOINC, at least as far as I understand since its widespread adoption to the long list of vendors. If I'm wrong about that, please correct me.
But I guess I found myself scratching my head a little bit on the way you were describing LOINC, because I always thought that it was the identifier that came along with the results that came back, only because you didn't know when you were ordering something, exactly what you were ordering usually, things like analities and all that. And you described this as being the question, but not the answer. Do I have things off 180 degrees?
Clem, I'll look to you, since you are one of the fathers of LOINC. Am I confusing things?
DR. MC DONALD: Well, you think of a question as a synonym for a variable or a parameter. It's just that thing that has -- the OBX segment of HL7, the variable can be sugar glucose, or the variable could be diastolic blood pressure, or the variable could be Glasgow coma score, or the variable could be some of the survey instrument questions.
And actually the nice thing about a question, and it has that connected thing and answer, whereas a variable has a value. So it's just a synonymous, and maybe easier for non-technical people to grasp if you call that result a question with an answer returned.
DR. COHN: Okay, thank you. So my world was not turned upside down. Thank you.
Marc, do you have any other comments on that one?
DR. OVERHAGE: No.
DR. FITZMAURICE: I guess if Simon is known for Mr. Business Case, you can think of me as Mr. Role of the Government. I'm looking at your next to the last paragraph, Mike Beebe. "Therefore, the AMA believes the government should limit its focus to broad recommendations for medical terminology framework with the specific code sets maintained by the private sector."
I don't think anybody has any problem with the private sector maintaining code sets, but I wonder what -- and I would maybe make a distinction between the role of NCVHS is to make recommendations to the secretary. The secretary then being part of the government, then takes action.
Is this statement then meant that the government then taking action, should limit its focus to broad recommendations, rather than saying we would mandate a particular terminology or a particular coding set or functions when the government interacts with the private sector? I think it's just my lack of knowledge of what that paragraph means, more than any objection to it.
MR. BEEBE: I don't think what it means about what you said about the government interacting with a vendor. When I helped write it, what I took it to mean was that the government should make recommendations -- this committee should make recommendations for criteria, rather than specific code sets.
DR. FITZMAURICE: But on the other hand, if part of the functions of the committee, or recommendations of the PMRI report was to make specific recommendations about codes sets or terminologies or whatever, that would seem to better serve the secretary, and then the secretary can make up his or her mind what to do with it, than to say, here are the criteria. Go forth and use the criteria. That's like saying here are some Ten Commandments. Let me tell you what's good and what's bad.
MR. BEEBE: I guess if the criteria were specific enough, then it would imply code sets go with the criteria.
DR. FITZMAURICE: But then that's like wiring it to a particular terminology or a particular code set.
MR. BEEBE: Right.
MR. BLAIR: Michael, you did your homework -- Michael Beebe. You went back and you took a look at that July document of 2000, and you saw the guiding principles. So you have stripped off the veneer, because you have looked at the fact that the criteria for selection was derived from those, and in fact we didn't import every one.
So I want to get back to the list that you said. First of all, we looked at that list, and when we were deriving the criteria for selecting PMRI message format standards, we looked at that and saw which ones would apply for message format standards.
And you identified several that we just didn't think we could quantify. They are good in general. We felt like all standards or terminology should have those characteristics. The same thing here. We wound up deriving them, and trying to look at those that would be appropriate for PMRI terminology.
But since you went back to those, I thought you might be telling us that we might have overlooked some of those. And do you want some of them brought back in? And if so, which ones would you want brought back in? And could you give us some feeling for how we might be able to quantify or measure them? Because that was the reason that we left them out.
MR. BEEBE: I'm trying to find that listing. I think that there were some that I felt were good, and should be applied to terminology standards. I think many of the more practical elements of the list of the HIPAA guiding principles should be relevant for PMRI standards as well. And the reason why I think that is because I think that you are dealing with basic issues of market acceptability and clinical context.
That this is something that is going to be used by physicians and other providers in the health care arena on a day-to-day basis for patient care. And as Clem said, we shouldn't go into these kind of more ephemeral notions that are outside of what is currently being done. So I think that there are elements that are practical rubber meet road type issues that we need to pay attention to.
DR. MC DONALD: I would like to address this to Michael Beebe about just the consistency. There is the cost question that I worry about when we make something a standard, which would imply some degree of that's all you use. And could you speak to the costs, at least in general terms?
So in a typical hospital, who has to really be licensed? Or how many licenses do you really need in to the hospital if you use CPT? And can you send it to anyone else in a message without having the receiver be licensed?
MR. BEEBE: I'm always asked about the cost question here. I'm more than happy to answer your questions. Unfortunately, I have to correct you. You probably pay more than a nickel for CPT updates. But thank you for the low cost estimate.
DR. MC DONALD: I think it's $35 or $100, or something like that.
MR. BEEBE: It's pretty cheap, $50. At any rate, to put CPT codes on a HCFA 1500 form or into an HL7 message format, it's nothing but one, two, three, however many CPT codes are necessary. We don't charge for transactions from hospitals. We don't charge providers or payers for that.
We do charge the cost of the data file, which is $50, plus $10 per user for licensees. That's our flat rate. It's on the Internet site. We have information regarding discounts based on volumes, but that's our basic user rate.
DR. STEINDEL: Well, one of the most fascinating things that I found in this session was of course Jim's new idea of thinking about things, looking at things. And I still have some nitty-gritty questions about it, but I haven't really formulated them well.
The big concept that I have in dealing with this is what is contained in the core? And how does the core relate to layer two? And how much of layer two is in one sense subsumed in the core? And how much of the relationship between the core and layer two is contained in the information model? And I think those are things that we need to think about if we think further about this type of model.
DR. CAMPBELL: Well, would an example be helpful?
DR. STEINDEL: Sure, that would be very helpful.
DR. CAMPBELL: We had recent discussion with nursing about goals. Goals are something that should occur in the medical record. They are part of guidelines and interoperable care plans. Let's say that for the sake of discussion that the core contains findings, assessments, procedures, treatments, medications. Let's say it has those.
And we sit down with the nursing associations, and we come up with a meaning definition of goal as a finding that we want to observe at some point in the future, or possibly not related to a specific intervention. From that, you can construct a semantic model for what a goal should be. It would be a finding with these attributes, date of evaluation, procedure, responsibility, and this type of thing.
All of those things -- well, some of them would probably map to HL7, because dates and stuff like that --
DR. MC DONALD: They explicitly define goals in the HL7 models, along the lines that you just described.
DR. CAMPBELL: Right.
DR. MC DONALD: It's a mood.
DR. CAMPBELL: But again, that's something that hasn't been discussed very widely with standards organizations. But that would be an example of how a concept out of a nursing domain negotiates its definition, if you will, with a reference core.
And then the legacy terminology, the goals that have been part of nursing terminology efforts in the past could be modeled into that. And now that legacy terminology is part of the convergent terminology systems. And they also have the recipe, if you will, for building goals for new care plans, et cetera. Everybody understands what a goal is.
But it doesn't, in that case, really require a lot of new elements. It requires creating the context that links those things together.
DR. STEINDEL: That's the one thing that I saw that was very fascinating about it, and goes along with some of what Margaret was saying, and the linking between clinical document architecture, and the structure in which something is sent. And the way the terminology is used in its context make it less ambiguous.
DR. CAMPBELL: I think there is a constant tension between standards development organizations and these schemes, which are really context-ridden situations. They can all be served, but we just have to come to some agreement about what their definitions are.
DR. FITZMAURICE: A follow-up question with Jim. Do you see the core layer, as you described it, being something or being equal to the reference information model? And so would your recommendation for the use of that model be that when a standard developing organization develops a standard, that it map itself to the core, and then back out to the particular function that would be in level two?
DR. CAMPBELL: See, I deleted that item from the requirements list, because in fact you created the reference terminology model as a part of the process. You basically enabled those candidate reference terminologies that are most mature, and powered them to collaborate, and encouraged them to do so to completeness.
DR. COHN: There was actually a question for clarification. Introduction yourself.
PARTICIPANT: I just wanted a point of information from Michael Beebe. You mentioned the survey of physicians regarding attitudes towards HIPAA. What was the date on that survey, and how many respondents?
MR. BEEBE: In fact, I think we just got the results back last week or the week before, so it's a very new survey. I don't have the information on respondents. I'll give you my card. If you send me an e-mail, I'll get you some more information.
MS. GREENBERG: Obviously, Jim, you caused some interest here with your model. And I'm trying to understand why there are some classifications in the second layer, and others in the third layer. You have DSM and ICPC in the second layer. Is that because of their relationship to the convergent --
DR. CAMPBELL: First of all, something I do share with Marc is we're both pragmatic. And one of the pragmatisms that separates some of those is whether or not we have any realistic likelihood to manage their content. And ICD is obviously got an existence of its own, and its own set of purposes. Whereas, ICPC, that's meant to be basically classifications of activities for primary care.
I have had primary care doctors talk to me about for example SNOMED, and how they could use SNOMED in their practice. And they say, see, some of these things that I see in ICPC aren't well represented in SNOMED. So that if there was a dialogue between SNOMED and ICPC, and there were definitions set up for what those were, I would hope that that those basically could come within the core, basically. And the primary care physician then would feel better served in this whole process.
MS. GREENBERG: Of course there is also a dialogue going on between ICD and ICPC, and of course there is also comparability between DSM and ICD.
DR. CAMPBELL: The other reason I drew the line between the second and third layers is whether it is primarily necessary for the clinical environment. So you can argue whether ICPC is necessary for that. It seems to me a logical discussion that it could be.
MR. BLAIR: Jim and Marc, maybe you could help me clarify this. I had the impression that there is a different approach, a conceptual difference in the sense that HL7 developed a reference information model as a model that enables it not only to develop new messages, but principally to improve interoperability for messages. That's essentially the purpose of it. And that when you wind up doing that, you need to drill down to get to greater specificity. And you wind up drilling down to the semantic level.
Whereas, you Jim, are winding up saying you're starting with a nucleus, a core in your model that has a purpose of semantic interoperability. You're starting there. And I think, Jim, what you are saying is that clearly there needs to be harmonization or mapping between a reference information model, and the core of your semantic interoperability construct. And that may be different than Marc's or Clem's perception of drilling down from the HL7 RIM.
Do I understand this, or am I off base?
DR. CAMPBELL: No, I think you are absolutely correct. From the standpoint of semantic interoperability to support guidelines, let's say that a disease or a disorder should realistically have attributes let's say of what causes it, and what organ it affects, because those are common inferences.
For example, you might want to go back and find all of your streptococcal cases, whether it's impetigo or strep pneumonia, pneumonia, or endocarditis. And if part of the definition within -- now, I'm talking about the core reference model, and what I discussed includes an etiology attribute, a defining attribute of etiology. Then those types of things are supported readily within the information. The vendor doesn't have to add that type of knowledge.
Now, that is different than HL7's interest. It's not saying one or the other is bad or good. It's just two different things. When they put together their model of where assessment are, and what data records they connect to, and what fields are in them, the interest that primarily drove that was to make sure that you could look at an HL7 message for this order, and say you didn't include this element. And it should be there, because the RIM clearly says that that should be part of that construction.
So it's starting off with two different purposes, and it contrasts the environment where we've got good message interoperability now, and we are poised to move towards this sharing of knowledge, which is the next grand phase of what the Institute of Medicine pictured. And I agree that there is a lot of skepticism. That HIPAA requirements can basically create more work than we can do.
But I think on the other side of this, and this is something which is very far divorced from physicians in practice, because they've got no sense of how they are going to build a computerized record. They will know it when they see it, but I don't think they could build it.
And I think that you, ladies and gentlemen, have the ability to nudge that next step forward, because I think there are many in the vendor community that are waiting for clarity of what the tools that they are going to use.
MR. BLAIR: Marc or Clem, do you have any comments?
DR. OVERHAGE: I would differ a little bit from Jim's model in the sense -- not so much from his model, I should say, as to more the timing in the sense that I think that we have an opportunity to move forward interoperability in the nearer term by coming to some agreement on how to code at least, conceptual elements.
And that trying to get to the point of shared knowledge representation in the next three or five years is very ambitious -- very good, but very ambitious goal. And that they don't have to be intimately tied together.
Within the center of Jim's three layered model, the core convergent reference terminology, you could think of spoke radiating out from the center of that, that segregate the data, not that it should be separated, but conceptually segregating the data saying problems, symptoms, diagnoses maybe as one of those wedges that are represented in the reference terminology, are represented in existing established terminologies, whether it be nursing or ICPC, and are represented in administrative code sets like ICD-9.
I certainly agree with Jim strongly that to the extent that we can, we want to separate the clinical and administrative uses, and not be bound when we don't have to be, by the administrative uses, although sometimes that may be prudent.
So I think that a key difference maybe that you were getting at, Jeff, is that I'm not convinced that the most important thing for us to do in the near term is to build the knowledge base that ties everything together. It's good and wonderful, and I'll be very happy when that day comes, but I don't know that we need to hold up progress to include that.
DR. CAMPBELL: The point is we don't have to hold it up. In 1992, we had semantic networks and 30,000-40,000 concept nodes. Now, we have semantic networks within this model that I have described to you with 400,000 nodes. I mean the content has substantially changed.
DR. MC DONALD: I think that there are two distinctions in what I hear Jim saying. One is talking about we have facts about facts, a real knowledge which is sort of independent of the patient data. So if you know this fact, you conclude the other facts, the connections, which I applaud, and I think we can do those no matter what. They are like in the dictionary system. I'm oversimplifying.
But the other part is in the semantic node model you can create anything you want without any database, just make all these connections. And what I worry about, if we want to have a message to be interoperable, we've got to have the codes in specific fields be interoperable or remappable in some fashion. And we could have this beautiful network, but no one will know what fields get stuck in what fields, and we are still screwed.
So what I would suggest is that we have to worry about the overlap in the models, because there is a model within the semantic, and they don't necessarily fit unless they are developed tightly.
And the goal is a great example. How it actually gets modeled in HL7 as a goal is as a test result or a question in anticipation. So I want to have this test result be greater than three, rather than show me it's greater than three. It is actually a mood distinction, but otherwise it looks a lot like an OBX.
And you could make up a code saying glucose greater than three, and that wouldn't fit. You want to have just the code for glucose, and a place to say greater and less than, and a place for three. So you can end up, if we are not careful about how we do this, with a great vocabulary system and a great database model, which is sort of the message model, and we still aren't done.
DR. CAMPBELL: But you are arguing at the fringes of the compositional network. What I'm saying is the network itself has already expanded.
DR. MC DONALD: Well, I may be a fringe guy. I've been accused of that before. But I think we can't assume in one theory or another. We've got to get those things rubbing together real hard, and that's why I think Marc's idea about concentrating on a particular reference model, focusing on how this network would work within that context will make us get there faster.
DR. COHN: I think it's almost time for a break, but I obviously want to thank our presenters. I was actually just asking the people in the audience if there is an advice you would like to give to the subcommittee as we move forward? Would you like to come up and introduce yourself, we would be happy to listen to you.
DR. ELKIN: One of the things I would like to say to try to -- Peter Elkin, Mayo Clinic. I would like to say that it galvanized some of the discussion that happened this session, which I found quite fascinating actually is that most of the way that the discussion has gone is to talk about existing artifacts, talk about how we might do something with those existing artifacts, position those existing artifacts in order to come to a conclusion.
So we have talked about LOINC and SNOMED and ICD and other things. But in fact, to solve the problem, as we beat around the bush of this, we clearly need to think about the abstract pieces that we need to put together in order to make this work, and see how well the existing artifacts help to solve that problem.
So for example, if you thought about an atomic reference terminology, you would think about those core concepts that cannot be divided into anything further within the base terminology, that represent the core concepts within health.
Then somewhere above that are pre-coordinations that are within the terminology. They have a unique identifier, but yet they mean one particular concept toward that terminology, but can made up by two or more other concepts within the same terminology. You need to do that, because we like to hang medical knowledge off of some of these facts.
For example, colon cancer, which can be a malignant neoplasm of the colon, put together very nicely and mean the same exact thing. However, we need to say things about colon cancer that you can't say about the other things separately, like you can diagnose it by finding a polyp on endoscopy.
Then there becomes post-coordination, because we know the LSCT trial showed us that we can't clearly pre-coordinate a terminology large enough to represent all the things we might want to say. Post-coordination has exactly the same format and formalism as pre-coordination, but doesn't exist within the terminology, and needs to be made up by multiple codes.
So if you look of this system of interaction, it has perfect places to hang things that were talked about here off of them. For example, we talked about interface or colloquial terminologies such as the one that Jim uses in IBX. And clearly, this may or may not be able to be totally mappable to a reference terminology. I know for a fact that his is, and so the codes then function as interface terminology, and they can be within the framework without changing anything about the model of the system that it works under.
There are other things that need to be added, that are missing. And the point of this all is that as you start to build this sort of semantic interoperability with this model, and then look at the information model in the world, and code it by the exact same terminology, you can start to find a seamless transition between the world that we live in, or the information model, and the things that we need to represent, or the terminological model.
This, I think, forms a nice continuum in basis for how we need to go forward. And I think that we will find that each and every one of our products that we have today has some pieces of what we need, and in some ways are flawed. I think by exposing that, we can have the best opportunity to move forward.
Thank you, Mr. Chairman, for my two minutes.
DR. COHN: Any other comments?
MS. BICKFORD: Carol Bickford from the American Nurses Association. When we took a look at the grid that identified the various codes sets that were there, I wanted to bring to your attention that we may not have a code set yet, but we need to be thinking about that, and that's the public health environment, particularly in light of our bioterrorism initiatives and the discussions about those sorts of supporting pieces.
And there was also missing, a concept of wellness and health. We were very much focused on the pathology. And it may be embedded in some of the existing structures, but we need to be thinking about that as we are moving forward in a health promotion, chronic illness, wellness, survivability sorts of things.
And I would also invite you to think about being more expansive in your practice(?). It's not necessarily describing today's world, but pushing the envelope. So that as we begin to create new knowledge and new relationships, that whatever structure we put in place will support that.
There was one other thought, but of course it's gone, so I'll go sit down.
DR. SPACKMAN: I was listening to Jim and Clem talking, and wanted to just bring to your attention an activity that went on just last week, which was what we call the Context Working Group within SNOMED. Basically, we are going from the core reference terminology model, and recognizing that there are interactions between what we can define with the core reference terminology model, and the HL7 RIM or the SEND EV13606 standard, or GAR(?) or Open GAR, all these other architectures that basically say how do you make an assertion about a patient in a record.
SNOMED terminology goes so far. You can say pain or knee pain, but you can't say knee pain present in this patient at this time in this record. We always said that's the responsibility of the record architecture or the message architecture.
What we recognized is that there is a responsibility on the part of the terminology standard, and on the part of these messaging standards to identify our overlapping areas, to have a formal structure that we can both translate our representations to, and they need to be coordinated.
So when you talk about a mood of goal, there needs to be a representation, so that if somebody in SNOMED wants -- our nursing people say, well, we need a pre-coordinated code that means goal of having a lower cholesterol, we want a code for that in our record for some reason. That we can represent what that means, and explicitly identify the context in that. And also identify how that ought to be represented in the EV13606, or an HL7 message, or something else.
So it's that overlap area where I think we at SNOMED have recognized that we hadn't dealt with, and we need to do it in a collaboration. So it's Keith Campbell and David Markwell and myself and Judy Warren from the AMA, and a group of others working on how do we represent something outside of the terminology model to represent context, and how do we coordinate that with all these other models.
And I think those two together form what is in the center of Jim's model, if I can interpret what Jim said. I would like him to confirm or deny that.
DR. COHN: Thanks very much. With this, we will take a 15 minute break, and get together, and we'll be talking about next steps.
[Brief recess.]
DR. COHN: This is our opportunity to begin to try to figure out some next steps. I'm sure that Jeff in a minute, would probably like to put all of this together, but I am not certain that I can.
DR. STEINDEL: I have a very mechanical next step, if I can request this of Marjorie or Suzie. Is it possible, because I haven't read it, but would it be possible to get us copies of the ASTM-2087.
DR. COHN: I hope so.
MR. BLAIR: Is Peter Elkins still here?
DR. ELKINS: I would be happy to do so.
DR. STEINDEL: It had it mentioned quietly to a few people.
DR. COHN: Well, let me also be very concrete here, only because it's easier to be concrete, and then we can move off into the abstractions of exactly how we will get this whole thing moving forward.
We do have a day in October, I think the first day of the October hearings, where we could actually devote to getting additional input on some of the things we are talking about. I know we will have probably one day in December, once again, during our scheduled hearings.
So I am certain this will go into 2003. And I think as you know, we have not started scheduling sessions for 2003, but we will make time available. I think in my view, the intent would be for us to have a letter for the secretary by the June 2003 meeting. So just to have everybody -- sometimes people think it's too long, and other people think it's pretty aggressive.
Bill, do you have a comment?
DR. YASNOFF: If you want a letter in June, that means we have to have a draft in February, usually?
DR. COHN: No, this is a letter, this isn't a 30 page report. We need to have ourselves in a position where --
DR. YASNOFF: You mean we need to have a draft for ourselves -- the last time we did a letter, how many meetings did we talk about that last letter? It was at least two.
DR. COHN: Right. I think I'm sort of figuring we will probably have two-three sets of hearings before June in the first half of 2003, and we can devote some to those. So it means that probably if we are by March or April into a draft. Once again, I'm not saying for certain it would make this. I think it depends on how complex the information gathering is.
DR. YASNOFF: I'm sure it's ambitious or not. I was just suggesting that we think about -- because we have been through this now so many times, that if we want to have the full committee look at it in June, we have done this before, and we know how long it takes. And so let's be sure that we are on a reasonable schedule.
The other thing is, would it not be good to think about actually scheduling some dates for next year?
DR. COHN: Yes, thank you for that suggestion, because it did occur to me that even though we just started on our fall schedule of hearings, I think we'll send out notes to everybody and begin to check for the schedules for the first half of 2003.
DR. YASNOFF: Following up on Clem's comment, if we can decide on the dates early, we might have a better chance of getting back to this room.
DR. COHN: That's a very perceptive and well deserved comment.
MR. BLAIR: With respect to our target dates, I would like to keep the target dates that you set forth. I do personally feel like it is going to be challenge for us, not so much because of the time, but because of the gating factor of the meeting dates, the full committee approval. But I would rather keep those dates and strive for them.
DR. COHN: It sounds like we are conceptually in agreement that we do all agree that it's ambitious, given the complexity of the issues.
Now, I think we probably need to reflect a little bit based on our conversations today and what we heard, things that become obvious next steps. And I'll give a copy of the ASTM standards I think is a useful piece. But we ought to talk a little bit about what our reflections about how we ought to be organizing or otherwise this effort.
And then very clearly we are going to need a consultant I think to assist us with some of the work here. And we also want to reflect a little bit about the skill set that we think a consultant needs to have, as well as some of our comments may help us reflect a little bit about what we would like to see that person do.
Maybe we should just start off by our views on what we have heard, learned, or otherwise over the day. Comments? Jeff, do you have any comments that you would like to make?
MR. BLAIR: I was delighted with the testimony that we received today. The people really did strive to answer the questions. And I think for the most part there is not too much divergence from the criteria for selection, although it may get either divided into different criteria for different groups or categories.
And there was one person, I guess it was Michael Beebe who wound up saying this might be listed as an editorial of what was desirable. We could look at all of that maybe when we get together in October.
That was the other piece. I volunteered to Simon to go over all of the hard copy testimony, and pull that into a matrix. If you recall, we had a matrix of testimony from the PMRI message format standards testimony where we could, for each question, we could wind up seeing how all the testifiers -- because I don't know about you, but I don't have the capability to do all that cross-comparison without the help of a matrix.
So I promise to have that for the subcommittee by October, so that maybe that will also help us make some decisions in October on some issues that are a little bit more difficult to resolve, that we can't resolve this afternoon.
One of the things that I think that I'll probably also try to do to help the subcommittee resolve these issues is dig a little bit deeper into especially Marc Overhage's and Jim Campbell's models. And if I need to, I'll speak with each of them to get clarifying information, so that we could see if we could come to a consensus on which would be the best operating model for the scope for us as we go forward. I think that that might help.
And then the third area is one that Simon you just broached, which is we really will need to have a consultant to assist us. Here, maybe I ought to step it back this way. What Simon is referring to is we sort of visualized that today we would get information, testimony on the scope and the criteria for selection.
And then from here, we would decide how and when we would construct a way to create some type of -- a way to gather the information from the terminology developers in a manner where we could compare it, and see how they match up against the criteria. We certainly need a consultant to do that, and I think it's going to be much more demanding that it was last time when we did the message format standards.
I think we felt reasonably comfortable last time that we could have a questionnaire, review that with the SDOs, and then with their agreement, we then submitted it to the SDOs and they responded to the questionnaire. I think this time a lot of the terminology issues are more complex. And we will need probably an individual that has some medical terminology expertise to assist us.
Now, there are a number of ways we can do this. Simon, am I going into this too far? Am I ahead of you?
DR. COHN: No, I think we all have comments that we want to make.
MR. BLAIR: What I was thinking was that maybe in October, as we boil this down some more, we might be able to wind up saying, okay, here is the criteria, and here is maybe some of the types of questions we would like answered. And some of that information may be gathered off of Web sites of terminology developers, others from brochures, others from telephone calls, others from documents.
But I think some of the most important questions may not be able to be answered without having someone with terminology expertise follow-up on some of the questions with some direct telephone interviews, or personal interviews of some kind, to be able to really get the answers that we will need.
And then pull that together for us in a manner which is reasonably digestible. And of course that would be the feedback we would be getting from the terminology developers. Maybe sometime in the November-December time frame we could begin to then hear from the terminology developers themselves, in addition to supplement that information that has been gathered.
And then maybe in the January, February, or March time frame begin to hear from users of the terminologies to hear the strengths and weaknesses of the terminologies. And then maybe we could start looking at a draft in March-April.
DR. COHN: I guess I did want to make a comment. I feel like Mike had mentioned that I was Mr. Business Case. And I am sort of still struck on the basis of the hearings today, that I think we better be looking some, only because I think that it's one thing to have criteria, but I'm not clear that we have scope or focus yet.
And I did hear for example there were a couple of themes. We heard lab, which we sort of know there is lab terminology out there, at least for questions. And it seems to me that drugs was another one. And I think it's probably time for us probably at the next hearing to really get updated about what's going on with the VA-NLM-FDA effort, to sort of see where that is, as well as where it is pointed. I mean my hope is that it may have some relation to what we are talking about, but we better hear from them.
Now, the other piece around the business case of course is that it would be nice to hear from the people involved in the business of health care, both payers and providers and probably vendors trying to sell information systems of what they consider to be the high value piece.
Now, we may still at the end of the day come back feeling that absolutely a comprehensive terminology is without question, the way to go. But at least it will give us -- if we recognize that certain things are very high value things almost immediately, it might cause us to weight certain characteristics a little bit differently.
Now, the other piece that I thought I should bring up -- I'm just sort of making some notes from earlier -- is that patient safety is obviously a big issue here. And there is an IOM activity going on now looking at patient safety data standards. I know about it, because I sit on that committee. It's real early, but I think it would be useful probably this fall to hear from them, just to understand where their direction is, what they are beginning to see as high value activities or issues, just to make sure that we are aligned with them.
I don't know if that's an October or a December discussion, but once again, I think anybody we talk to would probably describe that as a high value part of the business case.
Anyway, those are just some thoughts that I had. Clem, do you have any?
DR. MC DONALD: I guess I wanted to ask what do we need to accomplish today? I thought the goal was to get clarification on the dimensions. I thought that was one goal, anyway of the criteria.
MR. BLAIR: Yes, we had two goals. One is we wanted to get feedback on the scope. Does it include everything? Does it have too much? Should we divide it up differently? Should we reorganize it? We did get testimony all day on the scope, including a couple of suggestions for a different way to look at it.
And then the other one was the criteria for selection. On the criteria for selection, not only is the criteria right, but is it appropriate for all different groups of terminology? So we got some feedback on that. And then the other one was the priorities we should have as we go forward. Should we be looking at front terminologies or convergent terminologies, or whatever?
And I guess there was one other question we had towards the end there was whether things should be ANSI accredited.
DR. MC DONALD: The other thing is why would you not do the same mailing out to the developers of the codes as you did to the message developers? We can do it -- I mean, it's a parallel thing. That might save time versus the three step thing you talked about. And you still may need to call them, but why not start with something that is simpler?
MR. BLAIR: I think we might be saying the same thing. I think we could do it, and that would probably maybe get 50, 60, 70 percent of the information, and then follow-up with having the consultant do follow-up.
DR. MC DONALD: Because you have a template for that already, I think from the same source of the template for the other one. And then we would kind of want to wrestle with that template just a little more if it's out there, maybe even between meetings, so that we could make progress.
MR. BLAIR: Although this list of criteria is fairly -- somewhat different.
DR. MC DONALD: To come back to that other theme, if you were a 300 bed hospital, and you had 500 patients, what would be the price for this? To understand the cost in these things. What prices for the individuals? Because that is what we are going to hear back screaming on, if we make this a required standard.
MR. BLAIR: What about this, Clem? If I pulled together, so that we could all look at it, the testimony that we got in terms of the questions that they answered. And then based on that, if I pulled together a derivative of that, which would be a first draft of a questionnaire that we could send out. And then we could all look at that in October, and see whether the question fits or doesn't fit.
DR. MC DONALD: I think that's a good idea. I just wondered whether you could do the first draft, do it by e-mail, and then we would do the final. And then we would be closer to finality in October.
MR. BLAIR: Well, I would try. I don't know on a time basis whether I could get it done early enough, but I will try.
DR. MC DONALD: We still might need another cycle, but that would save a cycle. If we are aiming for what, next June maybe?
DR. STEINDEL: Which means we have to have answers, as Bill pointed out. I don't agree with every word, but we give it one more month, March, to start with a draft.
MR. BLAIR: Simon, what is our meeting date in October? It's like the 22 or 23, something like that. So I have a chance to get you a draft.
DR. MC DONALD: Do other folks on the panel agree with that?
DR. COHN: Yes, I just think that as I said, my view of the testimony was such that I feel that we would have a lot more insight on potential criteria, and potentially approach than this issue of scope and high value and all of that stuff. And I heard some things that -- before we start sending this stuff out, to even identify the whole galaxy.
DR. MC DONALD: If we could get the questionnaire together, because it's going to take cycles, not necessarily make it sequential. And then we might have to come back and fiddle with it. But we have a better shot at getting something done sooner. Your last model worked pretty well, I just don't want to go through the same steps.
DR. COHN: You just want to accelerate it?
DR. MC DONALD: I guess I said that the last time.
DR. COHN: I think we are learning. We're getting better here.
DR. YASNOFF: Simon, I think that the business case issues for vocabulary are much more difficult than for the message format standards.
MR. BLAIR: It was hard enough for us to get information back on message format standards.
DR. YASNOFF: Right. And let me say it more plainly. I think that whatever recommendations the committee puts forward, are going to -- the committee is going to be recommending that some people spend some large amount of money. It may be the government. It may be providers. It may be health care organizations. But there are going to be in the aggregate, some large expenditures, much larger than for message format standards, I believe.
I think almost any scenario I can think of, unless the recommendation is do nothing, that some substantial sums of money are going to be involved. And so I wonder if it wouldn't be worthwhile to think about engaging a business consultant, and do a formal analysis of the business case. And at least present us with a framework to look at in terms of the real economic justification for having these terminologies.
So that when the committee makes these recommendations that are going to involve large expenditures, that there is a solid business justification for those particular expenditures.
MR. BLAIR: Now, when you say that, are you focusing on the business case for the development and maintenance of a PMRI terminology? Or are you talking about I think that it would cost users to implement it, or are you saying both?
DR. YASNOFF: Both. There are several different business cases. One is the business cases for the adoption by health plans, by providers, et cetera. The other is the business case. I think in general much of the testimony is that a single vocabulary would be better for everyone than if everyone develops their vocabulary. That, on its face, seems reasonable to me, but I think some quantitation of how much better, and how much value is generated from this would or could potentially bolster the strength of the recommendations.
DR. AUGUSTINE: Unless there has been work that has already been done on that, that's going to be very hard to quantify the long-term benefits of having a standard set of terminology. And it's going to become more and more important as the health care inflation is in double digits and greater, and the baby boomers start hitting Medicare. But that's going to be very hard to quantify.
DR. COHN: Brady, do you have some extra time? It sounds like we could use you on this model. I think you are beginning to put what I think Dr. Yasnoff is describing together. Like Bill, I have been persuaded in these environments that look financial, things that have graphs, that have dollars associated with them, that are done credibly -- and as you know, MDs don't do credible dollar graphs generally, except Dr. Fallon, who does do that in his spare time.
But generally, that is sort of the stuff that sometimes helps with public policy decision-making. So I think the things you were describing, even though you were saying some of this is speculative, you were actually beginning to put together some of the pieces that probably need to be reflected in this.
MR. BLAIR: The business case that you are talking about, and that Simon is talking about isn't just the cost in expenses and maintenance. It's also the value.
DR. YASNOFF: Just as an example, clearly the VA and DOD have developed vocabularies, or they would not be able to have working systems. And with some work, it may be possible to elucidate approximately how much they have already spent in costs for developing the vocabulary they have. And then you could say that --
MS. GREENBERG: They haven't solved this problem.
DR. YASNOFF: No, I'm not saying they have solved it, but they clearly spent some money on it. And so then you could make the statement that if this had been available, they would have been able to avoid these costs.
DR. STEINDEL: Simon, I think we are going to get some information on this, and perhaps some data tomorrow, because the Comprehensive Health Initiative, one of the charges from OMB is to come up with these types of figures. And I don't think -- if we look at the committee as wearing multiple hats, the hat in the terminology sense, I don't think we have to look at that issue, because we are going to be looking at it as part of our charge with acting as an assistant to CHI, and we'll be reviewing a lot of the data in that area.
As the business case is developing in that area, it's very obvious that one of the things that needs to be factored in is some of the non-quantifiable costs of not doing this. That's a very difficult thing to get your hands on. And a lot of the justification for doing this is going to be the cost of not doing it, the opportunity costs.
DR. AUGUSTINE: And another thing that should bolster the business case, even though it's not quantifiable is examples of what we could do with this. For example, physician guidelines. You would be able to have the ability to monitor guidelines, and to see maybe in the aggregate across the health system, or across the state or the country what are the physician practice patterns in reality, as opposed to just looking at ICD-9 and CPT codes, which is of course, an inexact science.
As well, this information would give us a huge opportunity with regard to risk and severity adjustment, something we are very lacking in right now. Which not only would help technologically in the research side, but also could be used to more finely tune our reimbursement systems.
DR. MC DONALD: I think I need to go back to the question about what are we assuming is the end game here? Because you have two -- we've got messages or data being moved around for lots of different purposes. In some cases there are standard codes in place, ICD-9, and it really does move around, and it works.
In some cases there are not standard codes in orders, test codes, et cetera moving around. So there is data moving now. There aren't standard codes. We would make standard codes, and we'd have the added value.
I think what you are talking about is text turning into codes. And I just make sure where we are talking about that, because that assumes a lot more, and it assumes either a huge component of labor activity that may not be received happily by the health care industry, which is trying to reduce costs. Especially physicians who have ten minutes to see a patient, that had half an hour last year. Or some big progress in natural language processing, both of which should be considered in this analysis.
DR. COHN: Clem, can I propose a response? Maybe not a solution, but maybe it's something that we may want to think about. This is the issue of short-term versus long-term. I would suggest that whatever solution we come up, or whatever we propose, at the very least deal with what you were talking about when you started off about things that are ambiguous, uncertain.
DR. MC DONALD: Or whether there are slots for them, and they are moving around. Just what's in there, that's less of a leap.
DR. COHN: But I think that there is a case to be made knowing that there are a lot of people trying to work on these longer range solutions, that as you commented, are certainly not uniformly out there. That people are trying to make work. People are making relatively large investments in these sorts of longer range solutions, things that may provide more decision support, or more data capture capability, or whatever.
And the one thing we would like to do in those cases is to provide people that are making that investment, and putting terminology into them, that they don't wind up having to sacrifice their investment. So we would like to encourage those directions in ways that obviously are cost effective, and don't take too much more time. But you would like to provide people who are moving in that direction, if they are using this terminology, they know that at least they are not going to be sacrificing that investment.
Does that make sense?
DR. MC DONALD: No, actually it doesn't. If you look at the business model, you would say those people that are doing it, we would wait until we saw how they did it, and then we would copy them. Or we would do an experiment, and make it a research project. You wouldn't start building aircraft carrier assembly lines, because we are talking about this big, expensive thing.
As the first step, you would wait until these people had shown how to do it. I know a lot of companies that have tried to do highly detailed check off histories and physicals, and it didn't work. I don't think it had to do with a lack of a standard vocabulary. It had to do with the time cost to the user.
I like your goals, but how one would usually do this is not build a final model, and spend all the money before anybody had done it successfully. The natural line as processing is a way that it doesn't require huge changes in process. It is a way to use vocabularies very richly. So we might want to explore that too.
MR. BLAIR: When we went through our decision process on message format standards, one of the points that was extremely compelling was when we heard testimony from vendors that had spent a certain period of time, vendors and end users investing in the use of HL7 into their applications and their systems.
And so when Simon just said we need to recognize existing investments on the terminology side as well, I would think that it would be consistent.
DR. MC DONALD: I think it's consistent. I didn't hear that definitely. I know one place, your place. I don't know many other places. I think we should hear that testimony.
DR. COHN: That's why I say I think we need to hear from the vendors and users out there.
Steve, you had a comment?
DR. STEINDEL: Yes, I think we need to talk a little bit -- we have mentioned this in passing -- of what the scope of the letter is going to be. Because we heard some very interesting comments this morning from Colin(?). And the NHS has spent over 13 years trying to develop the terminology model to use in the UK. And they focused on the model that was described with the merger of three codes, the SNOMED RT and the development of SNOMED CT.
And we need to realize that their first roll out of the test of that system is still a year away. So we're asking the question, should we propose a terminology to use? And if we are looking at a comprehensive terminology, I think we have heard from many people that there is just one comprehensive terminology sitting out there, but where do we have good use cases for it?
I think we need to think about exactly what we are going to talk about in the letter. What things can we concretely propose, and what things that we can propose in the models. We need to focus on that. And I know that the CHI is grappling with the exact same question. We have heard today there is some low hanging fruit out there. There are some things that we probably can make some fairly definite recommendations on.
We got thrown a very interesting new way of looking at terminology from Jim Campbell, and I don't think we're ready to embrace that fully, and recommend it in a letter a year from now to the full committee. There hasn't been that much discussion in the informatics community on it. It was just introduced. It sounds very interesting, but how does it fit in with all the work we've done in the past?
And I think we need to sit down and focus on what the scope of this letter is going to be. And I think what we need to do from this meeting is what we had thought about originally, and that is define some criteria that is going to go out in a questionnaire that will go to the various people that are developing terminologies, or who think about terminologies.
Some people who don't develop them, just think about them, and what the attributes of what the selection criteria should be. And then ask the vendors themselves, the developers of the terminology, okay, how do you meet this selection criteria?
We heard a lot about overlapping terminologies, and we need to determine how much that is. We heard a lot of statements about looking at terminologies and different groupings, and different ways of groupings. And I think we need to ask the people do these groupings make sense? Should we explore terminology recommendations with these grouping points of view?
I think it's a lot of food for thought, and I think we need to move in small steps. The most focused step, I thought is Jeff is volunteering to put together a matrix. I think that is going to be very useful for us to focus in the October meeting. And an e-mail exchange of the draft questionnaires and draft questions between now and the October meeting would be very useful for us to have a focus to look at.
And whether we should have people come at the October meeting I think is a question that is still up in the air. It depends on how far we get. We may want to devote a half a day or a day discussing the food for thought that was presented today. It was tremendous.
DR. COHN: You know, I don't disagree. I guess I am struggling that we have heard from a certain group today. And I will say that I think we need to be hearing from some vendors, and from some users or potential users of all this stuff to validate it before we start getting too far down the road, to make sure that everyone thinks the same thing, and everyone has the same priorities.
But certainly you are right, there is a tremendous amount of good stuff here, and I'm really thankful to Jeff, or maybe a consultant if we are lucky, if we find one between now and then, will sort of put a lot of these things together for us. And I think we'll need to figure out about the business consultant.
I agree with Dr. Yasnoff that based on what I heard today, we better have a heck of a business case sort of associated with everything. But I am willing to believe that tomorrow we'll say oh, CHI is already doing that, so we'll just leverage what they are doing. I just don't know at this point.
DR. YASNOFF: I think I share Clem's concern about not trying to make recommendations that are going to force huge changes in process. But I think that whatever recommendations are made, need to be well grounded in a business case. And that if we are going to do that, and keep on our time table, you can't do an analysis like that in a day or a week, or even a month.
And if CHI is going to do it, wonderful. But I think that I think in this case a more formal approach to the business case is really an essential underpinning to being able to make the right choices about what to recommend. And then in addition, provides substantial backing for those choices in terms of the rationale when those recommendations are reviewed.
DR. FITZMAURICE: Everybody is talking in really nice sentences, and I'm just thinking like buck shot scattered up against the wall. I've got some bullet points to go through of some of the things that I picked up. They may make sense, or they may not make sense.
One of them is that I think I heard that the criteria are right. Mike Beebe said reconsider the original HIPAA criteria. There are other measurement problems with it. I think we're on a really good sound footing with the criteria. Where to start the labs --
DR. MC DONALD: Could I just --
DR. FITZMAURICE: I can't get out the first bullet.
DR. MC DONALD: Oh, do you want to do it as a buck shot, or just saying it's buck shot? I think the issue about usage, and most of the candidate codes have usage, so it won't screw anything up, and it won't be hard if we ask them, is there market acceptance or usage. I think that's not in there now.
MR. BLAIR: It was. He mentioned actually -- I was trying to get clarification from him, because right up at the very top, most of the things he mentioned were right up at the top. So I was trying to find out what was it that we were missing that he thinks should be included, and I didn't hear anything.
DR. MC DONALD: No, I meant to say that's a very good point, and you should keep on moving.
MS. GREENBERG: I think scope is important here, because I did hear from several people that depending on what's in scope, there may be somewhat different criteria for different aspects of this whole animals.
DR. FITZMAURICE: Next bullet, where to start labs, drugs. Do we need a model? What is the demand for linking medical record information? And I would look to the DOD and VA for answers to those.
In a lot of different things that I've gone to in the past couple of months, everybody says let's start with labs, let's start with drugs, because there is some infrastructure already there, and because it's very important for quality and patient safety. So I think that's a good place to start.
Economics of terminologies, this is the third bullet. I heard a lot about economics of terminologies. What is the value relative to the cost? What do you do with the market structure when you make a recommendation? How wide is our scope in terms of making recommendations?
Next bullet, a vision of interoperability. It was kind of brought into the terminology adds value to existing or future databases. That can add value to legacy systems if you can map them, to research, to syntheses, to clinical practice guidelines, because you can grab them when you need them.
Nursing codes, another bullet. We talked about goals. I can see that they can be used for improving health care processes, not just better care for the patients. Do we have the right processes for care of patients? Is there a process that works better?
The next one, mapping. Should codes and terminologies map to a specific reference or information model? What is the value of mapping? Should we recommend that adopted codes and standards map to something? I don't know the answer. It's a little to consider.
A lot of the criteria we heard dealt with the quality of codes and terminologies. And they seemed to me to be very good criteria, especially the ASM criteria. Are some of them too granular for our purposes, for our recommendations, as we could never get that specific information about them? Or is there a lot of subjectivity to them?
Are people aware of what is the quality of the existing codes and terminologies when they use them, or are they focused on their current purpose? Do we do a service by proclaiming these criteria that we are developing not only for our choices, but other people use them to look at quality of codes and terminologies?
Another statement, in the long run terminologies are not independent. Which got me thinking, is there a natural, desirable path for progress to getting to where we want to go? Is this a normal working of the market? Can we move the market along, or does it require strong government intervention? What incentives are reasonable to move it along?
Timeliness is an issue. Should we recommend a process for adoption, development, and maintenance? Right now we have a regulatory model, where HIPAA is the regulatory model. Are there other models that might work better for terminologies and codes that what currently have out?
A piecemeal approach or a whole terminology approach? What is the value relative to the cost? But I think we are kind of committed to the piecemeal approach. To do a whole process approach would be very expensive.
MR. BLAIR: I thought that what Jim Campbell was proposing was even if it is a stair step approach, he was giving a model which I thought was saying that -- actually, a number of people I thought were saying their priority was start with the clinically specific core first, because the other terminologies need to relate to that. And also because the other terminologies will have a subset of our criteria. They don't have to have the same full criteria as the core.
DR. FITZMAURICE: But I think the time it would take to build that core model and to describe it, just to describe, it would take a long time. So it would be like a black hole. But eventually the black hole gets filled up, but I'm not sure we know when we are halfway up the black hole.
MR. BLAIR: Then you're just saying we should abandon Jim Campbell's approach?
DR. FITZMAURICE: No, I think the concept is beautiful. I like that model as a conceptual model. But in putting meat on it, and then making recommendations based upon linking, and making recommendations about this has to map to that, I think that's a much harder process.
MR. BLAIR: Well, then let me back up a second. Maybe I didn't understand what he was proposing. I thought he was proposing an alternate scope for us, an alternate way of organizing the scope model that we have.
DR. FITZMAURICE: I'm not sure that I can describe it in those terms. I thought of it as here is everything in the middle that helps you take care of a patient. On the outside here are the departments that are organized around taking care of patients. On the outside of that is here are all the administration and the infrastructure needed for payment and for other purposes.
MR. BLAIR: Right. And I thought he looked at the graphic that we offered as an example, the starting point, the scope, to see what's in, what's out. How does it relate to each other. I thought he was saying that he was suggesting his representation would be a better way for us to look at that, and that would help us organize and prioritize what we look at.
DR. FITZMAURICE: What I see in his model, the inner core is a lot of not just things to do, but relationships. Those things are related to each other.
MR. BLAIR: Right, and as we wind up going through our evaluation of standards, if we don't know what the core is, how are we going to evaluate whether other terminologies map or relate well to that core, whether it's a reference terminology, a convergence, whatever it may be, whatever it is.
DR. FITZMAURICE: That's a point well taken, and I tend to think of it as we all have a vision of what we want to do with terminology and codes. I think our vision is very constant around the table. But the time it would take to describe it, and show the relationships might be better spent choosing particular standards. Doing a piecemeal approach until we build up enough things that it can fit into the core. But we shouldn't lose sight of the core. I think it's a great model for thinking about it.
DR. MC DONALD: Let me just interject that we are, I think, close to picking another code set, which is really a clinical code set, no matter how you call it for some purposes, ICN PCS. We talked about it last month. So that's already a piecemeal approach, no matter how you call it. So I think that operationally, for the next year or so, we've got to do some piecemealing. We are behaving like we are doing piecemealing. That's an order that can be used.
DR. FITZMAURICE: That's still consistent with Jim Campbell's model. It's just that we shouldn't spend time building that model. Maybe he's a better builder of that model. We should use it as our concept and say, here is where it fits together. We can point to it and say it fits here, or it fits out here, or it fits way out here in the things that we recommend.
MR. BLAIR: I sort of feel like -- let's see if this matches. What you are saying is that maybe it may be useful for us as a working revision of a scope -- we haven't decided that yet -- in October when we get all of our stuff together, we could look at it and decide whether or not that is a better, useful scope for us or not.
What you are saying is the implementation or the selection of terminologies within that model may or may not work from the center out. Is that what you are saying?
DR. FITZMAURICE: That's probably more specific, maybe more sophisticated than what I was saying. I was saying we shouldn't spend time trying to build that model. We are almost forced to do the piecemeal approach. And Clem pointed out we have already started the piecemeal approach. And that we should feel comfortable with that, because it will fit into our vision.
MR. BLAIR: When you build, you are not then saying this shouldn't be the scope for us to go forward for the next three to six months if we decide that in October then?
DR. FITZMAURICE: What I'm saying is I think our scope ought to be kind of piecemeal in nature. We should approach it as individual standards, and not worry excessively about does it fit into the center core of what Jim proposed.
MR. BLAIR: I would be uncomfortable in making that decision until we pull all of our stuff together and examine it carefully.
DR. FITZMAURICE: I'm not arguing for making a decision. I'm simply explaining what that bullet point, and what runs through my mind when I wrote down that bullet point.
DR. AUGUSTINE: It doesn't change the scope. The scope would still be the same. It's just the methods and the steps are different in the way we organize it.
MR. BLAIR: Steve, did you have a thought on this discussion?
DR. STEINDEL: This was one thing that I was thinking about when Jim was presenting his model and everything, the piecemeal approach versus do we have to build the core first and go out. And I think Marc, in his commenting on Jim's model also noted that yes, you can build it in pieces, and look at it just from a structural point of view and select parts and how they fit together into the whole, and where they fit in the various layers.
I think actually building Jim's model requires a whole new set of thought that we are not prepared to do right now. I think we all can conceptualize the pieces fitting together into some that builds that model.
DR. FITZMAURICE: I can agree with that. I think we are on the same wavelength, Jeff.
DR. MC DONALD: Steve, you said earlier this was just now introduced, it's not one that has been around. We haven't dissected and analyzed it. It's not something that is broadly accepted. But it's a good general kind of picture.
DR. STEINDEL: It had to me, a lot of nice places that I can hang concepts on, but just in the five minutes I've seen it, I just don't know where the hooks are for the hangers. And I would like to think about it, and I'd like to have broader discussion. But I think from a conceptual point of view, I think there are hooks, and I know there are hangers. And I know that there is stuff that I can put on the hangers that will fit in.
MS. GREENBERG: I also agree. I don't think that probably it would be premature to embrace it, although I think it generated a lot of good thinking about ultimately where you would want to go. And I think there are some real questions about what's in the second layer and what's in the third layer.
I think the assumption of the third layer was that they really didn't have clinical meaning, or clinical utility. And I think that's not necessarily true for something like ICF. I'm not going to say ICD, but I'll say ICF.
DR. MC DONALD: A lot of those administrative things are rich with clinical data.
MS. GREENBERG: So I kind of questioned that underlying assumption about the external layer, and then just differentiations from the middle layer. But also I think if you wanted to embrace that model, you would have to decide -- I guess you could ask people are you consistent with a reference terminology. But essentially right now there really is only one reference terminology, as I understand it.
So whether you are ready to embrace that, I think might kind of be putting the cart before the horse as you go out and try to collect information. But the idea that you want consistency, whether it be mapping or models, whatever, some kind of reference terminology could be something I guess you could embrace.
DR. STEINDEL: Just two comments that Marjorie's comments focused me on. Number one is I agree totally with her about the third layer. I'm not sure if there is a third layer. That difference between what Jim was putting in the third layer as administrative code sets or things that are involved in billing, as Marjorie points out, it blurs very much with what goes on in the second layer. And being one of the people at CDC who is looking at that sort of issue, I guess that's one reason why I see it as very blurry.
And the second is the other thing that I saw from Jim's model of course was when he was talking the core, and does it map to a reference terminology. I was rephrasing that statement in my mind as not does it, but can it?
DR. YASNOFF: The way I looked at that model was you have reference terminology at the core. The layer around it essentially are terminologies that consist of compound concepts or compound terms from the reference terminology. And the third layer consists of aggregations of concepts, either simple or compound into higher level terms. So that's the way I looked at it, which may not be what Jim meant. I was looking -- he's not here to answer.
And I think conceptual presentation is obviously very interesting and has been very helpful. Perhaps to stimulate additional discussion next time, it would be worthwhile to ask one or two other vocabulary folks to come to look at that model, think about it, and come and testify to us in terms of their view as to what its utility is, what it means, how valuable it is. And that might assist us in thinking through its value in a way that might fit into the timeline of our process.
DR. COHN: Yes, I agree. I guess the other question would be is whether or not sending it out to some people that testified today, and ask for their comments might also be useful.
As I said, I'm not ready to embrace it. I thought it was a very interesting piece. The helpful thing with conceptual models is that they help you conceptualize things. And if it helps, then that's great. And if it doesn't, we ought to find another model.
DR. STEINDEL: Well, Jim did a very nice job of phrasing the model. We need to realize I think a lot of components of that model were mentioned in other people's testimony today, like Chris' Web network, which I thought was a very nice concept, and a very good slide, is actually part of Jim's model, the way the second layer interacts with the first layer, and the information model that overlays it.
Margaret's mention of document architecture fits in with Jim's model. A lot of the HL7 RIM work is part of that. So there are bits and pieces of that model that were expressed by other people. So it's not really a new concept. It was just a very nice presentation of concepts that were presented earlier, and that have been presented in the profession for a long time.
DR. MC DONALD: I just had to clarify in Bill's comment, the compositional/non-compositional I don't think is quite accurate. The core actually had LOINC as the clinical drug, which I'm not using the right name for, and SNOMED. And all of them are compositional in some parts. I would call it the clinical drug, but that's an old word. I'm sorry, Archnom(?) is the right name for it.
They all have at least some things that are compositional. LOINC is in there, but I don't think we should pick on that basis. The big problem really is that we may run into these are political/social decisions. We may run into well, you put me into a second class code system; he, whoever has that code system. And it may create not what we really want to move this stuff forward.
And I think rather than say this is second class, it might be something is riper than something. Some of the other things are out there already. They are being used everywhere. So I think our first class, ICD-9 is right at the top of being used everywhere.
So a little bit of challenge I think in having this class level of these different code systems. And the bigger concern that I have is that we said in our previous letter that the RIM should be sort of the core. And we have to resolve where the first modeling occurs. There is vocabulary modeling clearly which is independent. But some of the vocabulary modeling can imitate the other modeling, and they will be different. And it's going to make it harder.
I think the only way we will make progress as in the other ones is somehow it's got to be piecemeal or stepwise. And we can do it like we did the other one, where we have a short-term thing that is more concrete, and a longer-term thing which is we did both of them, which is for the future, and try to set up the expectation of future things that will be for more funding, et cetera. At least I think in terms of that.
I think we should explicitly bless some of the level three ones. It's sort of like it's easy, because they are there already. So we can claim they are making a lot of progress. It's out there, the ones we blessed. I don't think we should just bless new ones, however we want to bless them.
DR. COHN: That was a lively bullet. I guess the bullet around this model issue is that we are really going to have to think long and hard about what is the core model that we are sort of thinking about. And, Clem, I think you have said it very well. Is it the RIM? Is it this conceptual model? Obviously, we have talked a long time about terminology models versus information models. But the question is we need to come to some way of describing that helps us, and helps the country.
DR. MC DONALD: Well, I think we have already said one thing at least in another letter, and we don't want to sound like we are kind of vacillating. I think really, they have to fit together is the key thing. And that means you can't just make a willy-nilly terminology model, and still say you mean that this is the RIM is the real information model. Something has to take precedence in that.
MR. BLAIR: That was kind of the question I was asking Jim Campbell. It seems to me as if he is proposing that while the RIM might be the information model, he is saying that we should consider a semantic interoperability model, which is essentially what he was drawing.
DR. MC DONALD: But you don't get to just say, okay, I'm going to name it different, so I get to do a different one. We want interoperability.
MR. BLAIR: We want interoperability, and I do think that there is a very, very conceptual difference here, which underlines everything that is going to happen with standards. I think we really do need to understand whether the best way to go would be with an individual model of semantic interoperability that works with, and that complements and coordinates with the RIM, or is the RIM the center of the universe, and everything works out.
Because if the RIM is the center of the universe, then we are going to have to deal with terminologies completely differently. I think in our message format recommendations we had a special paragraph that we added indicating that all other message format standards needed to coordinate or harmonize with the RIM, because we felt that interoperability was being driven by the RIM for message format securities.
Now, I don't think that we have made a decision whether that means all terminology should be derivatives of the RIM. I think we should discuss that.
DR. MC DONALD: I wouldn't suggest those words in any case; not that it's a derivative of the RIM. The question really is do you go out there and say this is how I think the vocabulary all fits together in some abstract sense? Or do you go and say this is what I'm sending around, and what goes in this, and what goes in this, and to make sure your vocabulary model has places of things that can describe what go in there. That's a completely different process.
MR. BLAIR: And Marc and you wound up saying you felt pragmatically you felt that we could move forward faster if we wind up saying what terminologies do we need to make these messages more clinically specific. That that is the way to go, in which case you sort of drive down from the RIM.
And I think that Jim Campbell was winding up saying there are other health care information objectives besides messaging that could benefit from his model. I don't know yet.
DR. MC DONALD: We've got a thought in the back.
DR. ELKIN: The way I like to think about what Clem is trying to get across is that you really have only two options with merging the information model and the terminology model. One option is that the terminology model and the information model agree up front to be non-overlapping and coordinated. Or two, they have to be overlapping, and where they overlap, they have to be identical period. Those are your only two options that allow you to have semantic interoperability between the data representation and the information model.
MR. BLAIR: Clem, did he say it right?
DR. MC DONALD: I think so. It sounded very good. What I mean is this is a serious problem, and we can't just say it will all work out if the vocabularists kind of have their fun, and the model is building on its own. What will happen is you are going to have fields in the model that won't have any stuff that belongs in there. You won't be able to figure out what goes in them. But what you might be able to do is make yet another way of doing messages, just sending words linked together by link words that are defined as link words.
So if you are really thinking about database structures, is what the world really does think in terms of when we are sending around understandable things, and that is the message world more or less, or object structures. You really have to figure out what are the things we need to make these messages interoperable.
And the HL7 in the best of worlds, you can make the messages be interoperable, but because the vocabulary and the specific fields is not, you really have only gotten maybe 10 percent of the way. So I view our big problem is to try to get those vocabularies standardized, and there are some sort of key pivotal vocabulary fields that we really have to worry about, and other fields like the patient ID too. But that's just old talk.
And some of them, we can deal with fairly rapidly. Now, this goal issue, there may be additional vocabulary needed when you take and represent -- there will be additional vocabulary needed when you get into the details, because it's not all going to be in terms of known measurements, which you could express now if you just handled measurements.
So that's additional vocabulary, but it's in a very strong context of the model. So we just can't go and build this grand model over here, and grand model over here and expect at the end we are going to have anything that works.
DR. COHN: Well, Clem, remember right before our break, Kent talked a little bit about the fact that we were getting together groups to sort of try to work on these tough areas. Is that sort of a view of how you begin to fix that from the terminology side? Is that sort of what you are referencing?
DR. MC DONALD: No, it's a job we have to do. We have to say we want to get to this goal. It's in the law. It says to exchange clinical information. Isn't that what the law actually talks about? Our goal is to find standards that will make it possible to exchange clinical information. We have already --
DR. COHN: Actually, study the issues related to da, da.
MR. BLAIR: And the electronic exchange of information.
DR. MC DONALD: I thought it was all couched in terms of the noun that we were dealing with is exchange of clinical information electronically. In that context, we have dealt with the message stuff to some degree. We have more work to do. And now we are still sort of screwed, because the message comes across, but I don't know what that means. That's 6592, and that's their words.
So I think we have a strong obligation to focus on the codes that relate to the messages that we are kind of dealing with, which puts you might say, some additional level of influence on the model. And I think that that gives us some guidance on where do we need to fill in these gaps the soonest. And there are some screaming ones for clinical drugs, for example.
So that's just a holler and a yell and a scream and jump up and down, if we only had that, life would be grand. But there are other ones. There will be lots of other ones in subject areas, and they could be filled in. We could go to SNOMED and say, well, gee, you've got all these things.
Now there is also the issue of how we connect the world of all the vocabularies together, which is sort of outside of the message. In other words, I know this is a glucose test. Is that a chemical or a microbe? Well, actually we know, because we know the word, but there should be a database up above that can make those connections. And those are things that also industry will provide if we get some nice pivot point nodes lined up.
So I don't think that one really pushes the other, but we have to know where we are trying to get to. We can make a whole pile of vocabularies, and still not get to the communications.
DR. COHN: Clem, I'm sort of agreeing with not all of what you are saying, but some of what you are saying. Given that sort of view of the world, how do we advance at this point? Is the issue that we should get some people in from the vocabulary SIG in HL7, and talk to them about what they think are the screaming areas?
DR. MC DONALD: That's actually a different side bar. But that's a useful area, because they are concerned with what we don't have, or what's not there, or what to standardize on, and I think that would be a very good area, and you have some broad representation. Some of the people here are.
DR. COHN: Yes, and obviously Jim Simino(?) was unable to come today, but he is a co-chair as I understand. So we should obviously have him perhaps talk a little bit about his view. But do we need that, or do we need somebody talking from the RIM about what they are discovering what the big holes are?
DR. MC DONALD: I'm just saying what are we trying to do? And I'm proposing we are trying to do what the law says, and we are moving in steps. And the next step is to get some standardized vocabulary, because we can get a lot of bang for the buck of we can get the vocabulary more standardized.
And who provides that standard, that's to be decided. But the scope should be decided about based on what the law says, and what we have done first, and what comes next.
DR. COHN: And I guess the question I'm still sort of sitting here with is this is very much of an information model view of terminology, which I do understand.
DR. MC DONALD: I'm not trying to push terminology into any bad world. I'm trying to say what is our overall task.
DR. COHN: No, I'm just sort of moving along here. This is the information view of terminology. You get statements that in this field you use one of these 40 elements from this particular terminology, and in that field you use one of 300 from that terminology. And so that's the type of interoperability handled.
The problem I have, and I at one point was director of data warehousing for Kaiser Permamente, a respectable-sized organization. But now you have all these data that you have now identified, and you have them in your database, but you have no structure to any of that stuff, so they are sitting there as you've got this term, you know the code. It's sort of like LOINC. You've got the code, but the question is now how do you structure it so that it becomes useful.
DR. MC DONALD: It is structured. I mean I thought you said it's in a database.
DR. COHN: Well, it is in a database, but it's just sort of sitting there. You have said this is the information. This is the data, but now the question is how do you make use of it.
DR. MC DONALD: How do you organize it.
DR. COHN: Exactly.
DR. MC DONALD: Well, that's like the encyclopedia. And that is kind of independent. If you've got the root codes, and I could take two or three different people's encyclopedia's, I mean hierarchies. That's like I can point out to this knowledge base. I don't have to shunt that back and forth. I can use that knowledge base, if it's coherent. Now there is a pure terminology world.
DR. COHN: I guess I'm saying that my view is that is some of the business case around why in the heck you would go around and actually get a terminology, as opposed to the codes on a bunch of different words. And I guess that was the point I was just trying to make. I think that we need to reflect the other piece of this whole thing, as well as -- but you are probably right that we need to be particularly careful.
MR. BLAIR: Dear, Clem --
DR. MC DONALD: You didn't really mean that.
MR. BLAIR: No, I do, I do. I absolutely agree with what you are saying is needed. I agree with the fact that it has been helpful for us to go for low hanging fruit, and to wind up doing things that could provide value, that's usable as quickly as possible.
What I'm arguing with you on is not any of the things that you have said. I'm arguing that I am concerned, and I know I'm not an expert. I am only concerned that while we do all the things that you say, that in parallel I think there is also a sense of urgency to move forward with that semantic interoperability piece, at the same time, in parallel.
Are we agreeing?
DR. MC DONALD: Yes and no. I don't know why there is any difference. I get a message, and I can send all parts of it. I have to have semantic identity.
MR. BLAIR: Maybe it's my lack of knowledge of where I thought there was a difference.
DR. MC DONALD: Well, Simon has a difference. There is a valid chunk of work there that is not what I'm talking about.
MR. BLAIR: And the thought that I was having is that there are health care information requirements that have gone without solution, without being addressed because of the lack of that semantic interoperability knowledge base. So not all health care intractable solutions are being addressed by messaging. A lot of critical ones are, and since we have HL7 and the RIM in place, we ought to exploit it as quickly as --
DR. MC DONALD: I'm not asserting that. I'm asserting that the messages don't work, because we don't have standard codes, so we don't have semantic interoperability. They don't do all the things we could do easily. It makes it very hard to communicate outside your organization. It makes a lot of work for mapping.
But I wanted to get back just if I could briefly to this knowledge tree of how you can classify and things. The perfect analogy is what the community pharmacy, the First Data Bank have done. They have taken this one little code, which isn't very useful. It's kind of sitting in a database. And they can let you aggregate it lots of different ways. Is it Medicare approved? Is in it generic? Is it not in generic?
If we get these base codes done, there should be a huge flowering of that sort of stuff, because there will be all kinds of opportunities to aggregate, classify, identify specific connections relationships on those things. And we might propose standards on that too, but that's not as key as having those first root ones. The NDC made all the rest of that possible, for all its ugliness.
MR. BLAIR: Did we agree or not?
DR. MC DONALD: I think we're going like trains passing in the night.
MR. BLAIR: I just felt that there is a balance that needs to be done here.
DR. MC DONALD: See, I'm not saying we should make everything -- it sounds like I'm saying HL7 iber alis(?) or something like that. Somehow it's that if we are dealing with the goal of sending stuff across, we always have to have a message in the vocabulary stuck inside fields. If you just send me glucose, that word, I don't know what the heck you mean. Is that a test? Do you want an order? I have to have it inside of a field.
If you send me a whole string of words really greatly granular, beautiful vocabulary words, I can say anything I want. It's just a string of words. Hello now today 5-7-12. I've got to have it in some kind of a database structure or an XML structure, something that gives me that context, the fixed context.
Now, you can imagine a pure vocabulary context generated world. That is, that could be imagined. But that's not what we are living in right now.
DR. COHN: Clem, is the answer to our question without trying to argue it any further is that we at least need to do what you are describing, and if at all possible, we should be doing what I'm describing?
DR. MC DONALD: I think the question is whether we have to standardize that are not, or we just want to encourage the industry to provide that. Yes, we also have to do what you are describing.
DR. COHN: But it's almost like at least we should do one, and hopefully as far as one or the other as possible. But am I off?
DR. MC DONALD: No, you're not off. The question is, and that doesn't mean that current messages are messages without more vocabulary are doing everything that can be done. I'm not trying to say that. I'm just trying to say to step back. This is how it works in the world. So I'm going to send stuff across in some kind of database structure. We need to make sure that those ones that are going across now and in the future have common vocabulary notes, fields, so that when it comes across, my machine can use it.
DR. COHN: At least, and preferably it means there is some agreement on how all of these things fit together, so that if you do actual retrieval, maybe my retrieval sort of looks like your retrieval.
DR. MC DONALD: Well, now you are talking about this external information about that code that says that it also is a this, and glucose is a carbohydrate. You can go on and on and on. It's part of honey, or is that fructose? You can go on and on, and in different worlds that will be tremendously useful, because then you can do logic on it. So, yes, it's just that you've got to get that base thing standardized at least.
DR. COHN: I think we're in agreement.
DR. MC DONALD: It's good to know that we have separated out what we are talking about.
DR. COHN: Okay, other comments on this one?
DR. STEINDEL: I was going to say I think once you get down to the right terminology, there is agreement, because that's what I was hearing. And I think we heard it a lot from the people today too, a lot of what we are discussing.
And Peter's comment at the end about the continuum between the information model and the terminology model is sort of what we are talking about here. And I thought Peter summed it up very nicely just a few minutes ago when he said there are parts of the information model and the terminology where they overlap.
Where they don't overlap, you are dealing with the areas that the models don't cover. The terminology model has parts, as we have heard, that won't be covered in the information model.
DR. MC DONALD: It fits in thought.
DR. STEINDEL: But it fits in. And that was the other thing that came across, was that we need to define the ways that the terminology model does start to fit in. I have used the word, and people hate me when I use this, that we need to define a grammar on how we combine things in the terminology model so that it fits the information model. You can use different words.
DR. COHN: Well, Clem, do you agree with what Steve was just saying?
DR. MC DONALD: It's a real tricky thing. You can stick a grammar in there, but most places like to have that bigger code. The one you were talking about is a combined one so you can process these.
DR. COHN: Okay. Do you have any other bullets there?
DR. FITZMAURICE: No, I think that's all my bullets.
DR. COHN: I think we need to keep this in mind, because this really is the information model versus terminology model.
DR. STEINDEL: We have to stop that information versus terminology model. There is really a continuum there, and I think one of the problems that we are facing in moving this system forward is that we have had this thing. There is the information model, and there is the terminology model. And there are things that we just can't express in one model or the other model, that we have to combine the two to get the expressions.
I think Jim Campbell's medical guideline project that they are working on is one example of that. I know the example that we are playing with at CDC is the public health case definitions, where there is a blending of the two. Yes, we can define a term that says public health case of anthrax, which is different than a clinical case of anthrax. We can define two codes to do that. But really, a public health case of anthrax is a blending of the information model and information in a terminology model that is coming together and defining that case.
DR. COHN: I guess I'm trying to figure out what to do with all of this stuff. I guess what I'm hearing is that in October we ought to probably get some people in to sort of talk about this interface piece, as well as where the opportunities are.
DR. MC DONALD: Basically, though someday we've got to decide some boundaries. I don't think we need to keep asking people to keep -- it's iterative.
DR. STEINDEL: I agree with Clem. We've got to get something down on paper. We've been talking about this for how long now? I don't mean this group, I mean just the profession itself. And I think we are sitting at a point in time where there is a coalescence of a lot of groups that are coming together.
And we are going to see those groups coming together tomorrow that are looking to us to say get something down on paper that we can start moving forward with. They are not saying get something down perfect. They are saying get something down we can move forward with.
DR. MC DONALD: I would suggest we listen to tomorrow, and take all the ideas, and then propose a scope ourselves. We've got to do some of our own work. It's sort of like a boot strap. Somewhere you just have to, by abstract principles, decide something. And then within that, work. Maybe we'll get some other good ideas tomorrow that will push forward on it, some specific things.
DR. COHN: I don't think I have much more to say.
DR. MC DONALD: I think we ought to have a reading of that paragraph of the law.
MS. GREENBERG: Standard patient medical record information and its electronic exchange.
DR. MC DONALD: Is that memorized, or is that exactly the words?
MS. GREENBERG: It's standards for the --
DR. MC DONALD: The exchange of. Do you have the exact words?
MS. BURKE-BEBEE: It says that HIPAA directed NCVHS to "study the issues related to the adoption of uniform data standards for patient medical record information, and the electronic exchange of such information." And to report to you, "not later than four years after the date of the enactment of HIPAA." This was July 6, 2000.
MR. BLAIR: Our loose end was we were going to try to see if there was agreement on the characteristics that we would look for, for a consultant to help us. And it may be more than one role. Should I just list out?
DR. COHN: I think we had already talked about the business consultant. I guess we were holding that conversation for tomorrow I guess.
MR. BLAIR: Right. This was for the individual that would help us gather, compile, and analyze the feedback we get from the terminology developers during the next several months.
DR. YASNOFF: That's one. And then other was I think what we agreed was that we wanted to assure that we have an appropriate business analysis available to us. That assurance might be because we get information that other people are already working on. Or if that does not appear to be the case, then we need to identify a person and essentially write a scope of work.
MR. BLAIR: I get the feeling that that probably would be a separate person? That seems like a different set of skills.
DR. YASNOFF: Yes, definitely.
MR. BLAIR: But here is what at least my thoughts were, and please tell me what I have overlooked or is wrong in this. But my thoughts were that this time it's going to be very important for us to have a consultant to help us that does have an expertise in medical terminologies, so that they could do the interviews, and ask the right questions, and get things clarified for us. So my first item was the expertise.
My second item was that they are dependable, reliable, organized, and last but not least, available in the time frame that we need them.
DR. FITZMAURICE: Jeff, and how about have writing ability?
MR. BLAIR: Yes, thank you. And have writing ability. So do you feel comfortable with that set of criteria for the individuals that we are looking for?
DR. YASNOFF: Jeff, what about the issues of conflict of interest?
MR. BLAIR: Oh, thank you. Yes, we would like to find somebody that would at least be --
DR. YASNOFF: I'm not sure you can combine expertise and no conflict of interest.
MR. BLAIR: Well, exactly. So I was going to rephrase. I was going to quickly, slightly rephrase what you said. We probably won't be able to find anybody with expertise that hasn't had experience with either standard development organizations or the development of one terminology or another. But we would hope to find somebody that is at least generally accepted as somebody who would render an objective, equitable analysis for us.
How about phrasing it that way? That still is hard to find, but we have a chance of doing that. No?
DR. MC DONALD: No, that's fine. I remembered something you said earlier that I didn't respond to correctly. You talked about, or maybe it was Simon, about bringing in someone in the vocabulary SIG, and I think that would be useful in terms of this. And it may be freeing, because I think there is a lot of freedom in the vocabulary. I don't know that. I think Stan Huff would be someone who would do it too.
DR. COHN: Back to our list of people. I don't want to name people. Obviously, we're in an open session here, but I think the key question is, are there any other requirements that we have for a consultant such as this? And if not, then we probably need to individually recommend to Marjorie or Jeff, people who might be good.
DR. STEINDEL: I think getting to Bill's point, I think we are all aware that there is a lot that is probably going to happen in the terminology area over the next year, both from a conceptual point of view, and also from a practical and business point of view. And I think that the person can't be involved in anything that is going on, on the outside.
MR. BLAIR: I'm not sure what you said. Can you say that again?
DR. FITZMAURICE: You want them to have a job, right? You don't this to be their sole support.
DR. YASNOFF: What you're saying, Steve, you want somebody who can be objective, but also you want somebody who will agree not to do something while they are doing this that grooms their objectivity. So they have to agree not to enter into any relationships that would create conflicts while they are doing this. It could be a problem, but I think that's a very good point.
DR. COHN: And I guess if anyone knows that single individual in the United States, or in the known world.
DR. YASNOFF: I think if you're willing to drop the expertise criterion, you will have a much bigger pool.
DR. MC DONALD: Actually, if we got a real good writer, who is a bright, intelligent, and a real good writer, they may not have to be as expert. If you get a call from The Wall Street Journal or The New York Times, they don't know anything about the field, and they talk with you, and they get it right in most places pretty much.
MR. BLAIR: I agreed with you in the message format standards. In this case, I think we do need somebody who really has at least some background with medical --
DR. STEINDEL: I think it's desirable, but I think given the other criteria, it's probably going to be very difficult to find that person.
DR. YASNOFF: There is another possibility, which is you could consider having two people. One to help you gather the raw information, and then a second person to help with the writing of the recommendations. That person doesn't necessarily have to have the expertise. So I'm agreeing with you, Clem.
DR. FITZMAURICE: Could I make a suggestion that Jeff put out the criteria, give them to Marjorie, and then Marjorie sends around the criteria, and say, would you please suggest any names of people you feel meet the criteria. Then we can look at the names.
MR. BLAIR: We just are saying give us some other names, based on our conversation. Don't wait.
DR. COHN: With that, I'm going to suggest that we adjourn for the day. We have our meeting starting at 8:30 am tomorrow. I want to thank you all, and sleep on this.
[Whereupon, the meeting was recessed at 5:35 pm, to reconvene the following day, Thursday, August 29, 2002, at 8:30 am.]