[This Transcript is Unedited]
Hubert H. Humphrey Building
Room 505A
200 Independence Avenue, SW
Washington, DC 20201
MR. BLAIR: Good morning. My name is Jeff Blair. I'm chair of the CPR Work Group for the National Committee on Vital and Health Statistics. For those of you who are listening on the Internet, we are convening about ten minutes late.
Just to put in perspective for those of you who are tuning in or are here for the first day, the context of these hearings. These hearings are part of the information gathering activities that are part of the Health Insurance Portability and Accountability, the administrative simplification provisions.
Among those provisions is the requirement that the National Committee on Vital and Health Statistics study the adoption of uniform standards for patient medical record information, and the electronic exchange of that information. That is the mission of the CPR Work Group, is to focus on that particular requirement with HIPAA.
The way that we have proceeded on that is to identify focus areas in order to do that study of uniform standards for patient medical record information. Those focus areas include: message format standards; medical terminologies that relate to patient medical record information -- all of these things of course relate to patient medical record information; business case issues; data quality; accountability and integrity issues; the relationships to the national health care information infrastructure; and the relationships to privacy, confidentiality, and data security; and lastly, the impact that different state laws might have on the uniform standards for patient medical record information.
The panel that we have this morning will be addressing those issues. We have two panelists that will be addressing those issues from the perspective of being users of standards and medical terminologies, and another panelist who will be addressing it from the standpoint of being a developer of standards that relate to patient medical record information.
Before we go to the panelists, let's go around our room here and introduce all of our committee members and staff members. Dr. Cohn, could we begin with you?
DR. COHN: I'm Simon Cohn. I'm national director for data warehousing for Kaiser Permanente, and a member of the National Committee.
DR. ZUBELDIA: I'm Kepa Zubeldia, vice president of ENVOY Corporation, and a member of the National Committee.
MS. BURKE-BEBEE: My name is Suzie Bebee. I'm a health informatics specialist with the National Center for Health Statistics, and I'm on the staff.
LTC. RUBERTONE: Lt. Col. Mark Rubertone. I'm chief of the Army medical surveillance activity in the Army.
DR. LAU: I'm Lee Min Lau. I'm from 3M. I work on the 3M health care data dictionary.
MS. GUILFOY: My name is Helene Guilfoy. I'm a health care consultant with Insource Management Group. I'm a member of ASTM E31 on health care informatics, and the subcommittee E31.19 on electronic health record content and structure.
DR. FITZMAURICE: I'm Michael Fitzmaurice, senior science advisor for information technology to the Agency for Health Care Policy and Research. I'm liaison to the National Committee and co-lead staff with Bob Mayes to the Computer-Based Record Working Group of the National Committee.
DR. MC DONALD: I'm Clem McDonald from Regenstrief Institute and Indiana University, and I'm a member of the committee.
MR. BLAIR: Is that everyone, or are there observers?
DR. FITZMAURICE: There are observers.
MR. BLAIR: If it's possible for you to get to the nearest microphone, then that way the people on the Internet can hear you. So can you introduce yourselves, please?
[Introductions were made.]
MR. BLAIR: That's it? Thank you.
I want to thank our panelists for coming today, and can I ask if each of you can introduce yourselves, please. Actually, you have when we went around this circle here. So maybe what I'll do is could I ask Helene Guilfoy maybe to begin the testimony. Helene will be giving it to us again from the perspective of representing a developer of standards.
MS. GUILFOY: Good morning, and thank you for inviting me to participate in this discussion. Jeff, I come from presenting today as a standards developing organization, but I also have the perspective of a user, since I have used health care terminology for more years than I care to count.
I want to talk you a little -- we're having some technology issues here with our Power Point presentations. I want to talk to you about the ASTM and its background. I want to talk specifically about the standard E13.84, which is the standard for the content and structure of a computer-based patient record.
I want to address the questions that you posed, why comparable medical information? What are the consequences if we don't have comparable medical information? What are the difficulties with existing terminologies? What are the companion ASTM standards to our primary standard of 13.84? And what are the emerging companion standards that we are currently developing at this point? And then leave some time for questions.
Thirteen-eighty-four is the primary standard of E31.19. It is the content and structure of a computer-based patient record. All of our other standards relate to this, and have attempted to have consistent information and structure based on the 13.84 structure. Thirteen-eighty-four defines all health related information about a patient over time. That's how it defines a medical record.
It insists that the record must have observations, and it defines observations as the physical exam results, laboratory tests, radiology reports, et cetera. It requests practitioner orders. They are a part of the content, patient identifying information. So all the demographics information needs to be a part of the structure. And then it also defines the legal parameters and how they should be included in the information.
It also requires that the information in a computer-based patient record be seamless. If you remember, I said that the content included all the information about a patient's health information over time. But it is important that it be transparent to the user that this information is coming -- whether it's coming from an ambulatory record, it's coming from an inpatient record, whether it is coming from a neonatology record, or whether it is coming from a morgue report. The information needs to be seamless and consistent over time.
It requires a common logical record structure which says again that the information be seamless, but that it also has a relevance to each other. Often when we look at the paper record we will have an inpatient stored someplace, and if we want to look at the emergency room records, we have to go someplace else to get those. And if we want to look at an ambulatory record, we have to go yet to a third place, or possibly a fourth, fifth, or sixth place. So it is important that this information in the electronic format be kept in a common record structure.
It also requests that the information be commonly termed. In other words, that we use the same information in various parts of the record. If we are going to call something one thing in one part of the record, we don't call it something else in another part of the record, which we in health care have a tendency to do.
You asked the question of why do we need comparable medical record information? I would propose that we have many different disciplines in health care. Each one of those disciplines has its own outlook on what's going on, what the initiative should be with the patient. A cardiologist will look at things very much differently than an orthopedic surgeon, for instance, because they have their own areas of expertise.
So we have all of this information in all of the different disciplines. If we don't have the information that we can look at over time, and in a standard format, then we lose a lot of subtleties of the information. We need to have a common terminology to be able to be understood. It is not that the cardiologists and the orthopedic surgeons speak a different language, but their backgrounds are various and are different. The backgrounds more specifically within the other disciplines of health care -- nursing, respiratory therapy, physical therapy.
It's not that we don't all have the patient at heart. It's that we do speak a different language. We need to be able to develop a common terminology so that we can all be understood.
Having the comparable medical record information also eliminates the need for translation. When we have to translate information we often will confuse what is really meant by the information that you're trying to share. There is also the potential loss of the information. If it's not in a comparable, then we don't have reasonableness to expect that all of the information is there.
What are the consequences if we don't have comparable medical information? You're going to have to bear with me, because I know a couple of you have already heard this example in the past. Simon is smiling. In my role of being a standards developer I worked with some of our hospitals to develop common terminologies so that we could do clinical documentation. In doing that, we needed to go out and assess what they currently doing, how they were documenting things.
One of the things we found was that there were several different pain scales in use at this particular hospital. Oncology had their own pain scale, and they would report pain with different gradients. Physical therapy had its own scale of reporting the patient's pain, and nursing had yet again another way that it reported the pain, all of which was making a very brave attempt to assist each other, and to also assist the patient.
The problem was, and you'll see on this slide, one of the groups used the scale of 1-4, 1 being the least amount of pain, 4 being the maximum pain. That happened to be physical therapy. Nursing, on the other hand, used a scale of 1-10, 1 being the least amount of pain, 10 being the most amount of pain.
Well, you can imagine -- and looking at the smiles from those of us around the room that have been in this situation -- you can imagine what happens when the patient is in physical therapy and they have been put through the tortures of having their body twisted in places that they never knew it could be twisted in. And they reported out a pain level of 3. Physical therapy dutifully charted they had a pain level of 3. Because of the questions that physical therapy asked them, that's what they recorded.
The patient went back up to the nursing unit, and remember that the nurses used a scale of 1-10. Well, 3 is on the lower end of that scale. So when the nurses read the pain scale, they did not administer medication appropriately, because their determination was that the pain was not as severe as the patient was really having.
Now I'm oversimplifying this, because obviously there are clinical observations that go along. You don't just follow what's written on a chart. But my point is that unless you have common ways of documenting information, you are going to be misunderstood -- excuse me, you have misinformation.
The other side of it is that you could have misunderstood information. We have two different units of measure here in this country. Some things are reported out under the US system, and some things are reported out under the metric system. If that information is not brought back into a common way of interpreting the unit of measure, then again we can have a problem. I believe I'm right that it was the Mars probe that crashed as a result of exactly this very thing.
I want to talk a bit about the difficulties with existing terminologies, inconsistent definitions and terms. The one that comes to mind is patient status. In some hospital information systems patient status is also called patient classification. It's also called type of patient. In the X12.837, patient status is what is referred to in a hospital information system. When you look at the content of what patient status is, it's really the discharge information. It's whether the patient went home, whether they went to a nursing home.
So where we don't have the consistent definitions and terms, we need to be able to provide good examples. But better yet, wouldn't it be nice if we had consistent terms? I was surprised when I looked up patient status in the 837 format and found out that really the substance of it was discharge information.
Now some of you have already heard me talk about this also. I thought I would put it up here on the slide where we had difficulties with existing terminologies. In addition to inconsistent definitions and terms, we also have inconsistent values. And what you see on this slide is a comparison of the marital status as it is codified in four different established standards.
The UB92 captures marital status of separated as an X. The X12.837 captures the separated marital status as an S. The HL7 captures the same information codified as an A. And the MDS captures it as a 4. Now it gets worse.
The next slides shows that in addition to all of the previous different codified entries, you notice that the X12 captures separated as a codified entry of an S. However, in the UB92 and HL7 an S is really an indication of single status.
Here we have consistent definitions. We have consistent terms, but we don't have a consistency in the way that information will be stored in the computer. If I could digress for just a minute, from a user standpoint, and Lee could probably speak to this better than I on the perspective of a vendor, this can wreck havoc with our systems, because this means that when we transfer information to the lab, if the patient is single, we have to transfer it as an S, or if they are separated we have transfer it as an A. But currently when we file our UB92s, we file it as an X or an S.
So we have just confused all of the information from this perspective, but we have also confused it from anyone trying to pull this information out of the record. What do you pull? Oh, let me see, wait a minute, that information came from the lab, so I should probably pull it, if I'm looking for separate, I should probably pull it as an A. But on the other hand, that information went off to the insurance, so I should pull it as an X.
So you can see the vagaries in here, and where it becomes very difficult for those of us that are attempting to comply, and attempting to use the various standards.
I want to talk a little bit about the companion ASTM standards to E13.84. The standard E -- everything starts with an E, I apologize -- E16.33 is a specification for coded values used in the computer-based patient record. What this standard consists of is a coordinated effort at developing the code sets that have come from other standards developing organizations and the federal agencies.
If you go into reference 16.33, you will find -- well, starting with 13.84, you would find the data element for instance of marital status. And you will be able to take that information and go to the reference standard 16.33 and find out what the coded values of marital status should be as far as 16.33 is concerned, as far as ASTM is concerned. We don't make any attempt to say who is right and who is wrong in these situations.
Another companion standard to ASTM 13.84 is the standard 17.44, which is the standard guide for views of the emergency medical record in the computer-based patient record. There are lots of words in there, but what it really was, was an attempt -- remember, as I said we have many, many users from many, many disciplines looking at computer-based patient record. This happens to be one view of those people providing emergency medical services, whether they are providing it in the field or whether they are providing it in a hospital emergency situation.
The data elements that are contained in 17.44 are based on national guidelines for emergency care. We didn't go out and try and reinvent the wheel. We looked at the standards that were already out there, and incorporated those so that they were organized around the content of 13.94. So that you again had a logical record format. You had a logical progression of the information, and you had logical information. You had the same information captured over time.
You would be able to look at this patient if they were treated in the field, brought into the hospital, and then subsequently admitted, and subsequently discharged to physical care or an ambulatory service. You would be able to follow that information in the same format consistently in the electronic medical record.
The other thing that is important to know about the work at ASTM is as we were developing this standard for 17.44, we discovered gaps in 13.84. We were able to feed back those gaps into the content and structure so that we have now a more complete record than we did prior to the emergency record being established.
We have some comparative standards, companion standards that we're working on at this point in time. These have not been identified yet with the E designation, but I will just briefly tell you about them. We are looking at a pre- and post-natal view of the computer-based patient record. Again, using the same concepts that we worked out with 17.44, we are able to develop a neonatal record that is consistent, will be able to have the information over time, will be a common format, will be able to be used in the context of the electronic health record.
Work is also just about to begin on a master patient index standard, and again, looking at the information that is captured in 13.84, we'll be able to develop a more consistent standard for the patient record identifier.
I'm open to any questions. Or I don't know how you want to do this, Jeff, if you want to hold questions until the end?
MR. BLAIR: Helene, typically what we do is -- and I probably should have indicated this beforehand -- each person that is testifying, testifies for about 15 or 20 minutes. And then at the end, after everyone has testified we usually have about 20 minutes left for questions.
MS. GUILFOY: Very good. Thank you very much for your attention.
MR. BLAIR: Dr. Lau.
DR. LAU: Hi again. I'm Lee Min Lau from 3M. Thank you for having me here. My work at 3M is mainly on the 3M health care data dictionary. I'm also the chair of the CPRI task force for the promotion of standards and vocabularies. Hence, my interest. For this presentation, I have been asked to focus just on terminology, so that's what I will do.
What do we regard as the patient medical record information? We include both clinical and non-clinical data that describes the patient's information such as: patient's name, gender, race, religion, and such information. We also encounter-related information such as the insurance payer information, where the patient is located in the health care facility, who are the care givers, the patient's discharge disposition, and so on.
And last but not least we of course include clinical information such as the patient's complaint, his past history, family history, behavioral findings. The kinds of clinical stuff that you need to take care of the patient. To us, that patient medical record information must be linked to each episode of care, as well as across all the episodes of care so that a longitudinal, continual view.
Now what is meant by comparable patient medical record information? To us, we take it that the information must be comparable for a patient across all episodes of care, regardless of where the patient is located, or who the care giver is. For an institution, comparable patient medical record information should be across patients regardless of the departments, the facilities, and across time.
And for a country, across institutions, patients, locations, and time, so you can really look at this like circles that include each other. I would assume sooner or later we will get to the international view, where it will be across countries, and so on and so forth.
Comparable medical record information is required, in our view, for individual patient care, as well as for population-based sort of functions such as outcomes research, queries for administrators to make cost decisions, and so on and so forth.
Now what is required for patient medical record information to be comparable? We believe that each piece of data must first be accurately and precisely defined. I would like to make the point that the definition of the data is not the same as the data itself. So one could define the data precisely and accurately, while the data value may still be wrong.
For instance, you may have a good definition for hematocrit. You know exactly what it is, and the wrong data value may still be placed into record for hematocrit. I just want to make clear the distinction between the definition and the actual data, because you know we talk about what is needed for comparison and all those stuff. I would like to point out that both are required, but I'm only going to focus on the definition.
Now how does one define a piece of patient medical record information? Well, it includes but it is not only confined to the definition of the model of the information structure, which is really the identification of pieces of information that makes up a meaningful record.
For instance, one may decide that a medication order must have the dose, the form, the routes of frequency, when you start, when you stop, and all kinds of other information. When this definition is done you may include the data type and the precision such as dose must be a decimal value, and you can be precise up to two decimal points, and so on and so forth.
However, that is not the only definition required for the patient medical record information. Each piece of data item itself must also be defined so that everyone knows its meaning. For instance, what is a drop? How do you define an antibody? What's penicillin? What's ampicillin and so on? It's separate from the data structure of the information model or the medical record, which does says that a drop is one part of a medication order.
Now one also must include the synonyms of each piece of data item, as well as the relationships among the data items to make the definition complete, or to support the definition. Granularity, as well as composition/decomposition should be taken into account such that one knows at what level of detail one is defining the data item.
An example would be Catholic as a religion. I'm not one, so to me that was just Catholic. Someone pointed out to me that there is also Roman Catholic and Catholic non-affiliated. And those are like types of Catholics. So there is a difference in level of granularity here.
Now composition/decomposition as you all know, simply refers to whether a piece of data comes across as a single item, versus separate pieces of data that together make up the same data item. An example would be left upper arm as a single concept, versus left, upper, and arm as three different pieces of information which together makes up left upper arm, and has the same meaning.
So in other words the definition of patient medical record information in terms of meaning of each data item would include the functions of a vocabulary. These definitions must be precise and accurate for the patient medical record to be comparable. Preferably, the definition should be formal, such as that used by SNOMED-RT. And that's what we found through experience, because before we incorporated SNOMED-RT as a beta a site, we were doing definitions in an informal way, meaning we just write it out in English. That was adequate, but not exactly precise or accurate.
Now having precise and accurate definitions does not mean that the medical record structure, or each data value, or the data values must be identical. It means that if you know the meaning of each data item, the patient medical record information become comparable. And here is an example.
System A may define in terms of structure, a name to be made up of a prefix, a first name, middle name, last name, and a suffix. Whereas System B may define the name to be made up of prefix, the first first name, the second first name, the first middle name, the second middle name, and then the family name, and then the suffix.
I miss my good friend in Brazil a lot, so I use her name as an example. In System A she is simply known as Beatrice, first name, Compose(?), middle name, Rocha(?), last name, M.D., Ph.D. if there is a suffix, which is interesting to me, because I have always thought of suffix in the American system as being just junior, senior, and so on. So I'm Chinese. We don't have suffixes. But I have seen from our customers that definitions such as M.D., Ph.D., Pharm.D. and so on got put into suffix.
Now in System B my friend, having a prefix of doctor, the first first name of Beatrice, the second first name of Helena, the first middle name of DeSouza(?), the second middle name of Compose, family name of Rocha. So the structure is not the same. The data values are not identical, but if you have defined what exactly is the first name, middle name, and so on, and you can therefore relate between the two systems, and figure out how comparable the data are.
Now what are the terminologies used in the 3M health care data dictionary? The 3M dictionary is really a working product. It is not a standard developing sort of thing. We don't develop standards or terminologies, at least definitely not directly.
We use existing terminologies, and these are the ones that are currently incorporated: SNOMED, as well as SNOMED-RT, as I said we are a beta site for SNOMED-RT; the UMLS; LOINC; NDCs, and we obtain those from First Data Bank, as well as the related hierarchical and ingredient and what not information that comes with NDC; ICD-9-CM; DRGs; CPT4; and HCPCS.
Now what are the issues encountered in using these terminologies? First of all, we run into the problem of some of these terminologies being what I consider to be classification schemes, versus others that are controlled vocabularies. So for instance, ICD-9-CM is a classification scheme to me. SNOMED would be a controlled vocabulary.
Now the issue here is that a controlled vocabulary deals with discrete concepts, whereas a classification scheme would deal with buckets of concepts. They are really groups. An ICD-9-CM for instance, may be as small as a group of 1. The basic principle is it is still a group, and at any time in the future more members could be added to the group, keeping the same code. So that to me is the difference between a classification scheme versus a controlled vocabulary, and we have to deal with of these in the dictionary.
The next issue would interface terminologies versus a reference terminology. Interface terminology is whatever the user, an application wants to use, versus what comes across as a standard reference terminology. So an interface terminology for instance would be interface codes being sent across in a message from a particular customer's legacy system, whereas the reference terminology would be SNOMED or LOINC.
Another issue is incompleteness. By this I mean both that the reference terminologies used in the HDD may not be completely implemented. Now how do I put it? For instance, take LOINC. We use LOINC for the lab results names. Well, LOINC is very comprehensive, but certainly does not have all the possible lab results. That's what I mean by incomplete in one sense.
Another area where incompleteness is seen is an example would be in a hierarchy. Our drug database from First Data Bank, for some reason, is not at the moment multi-hierarchical. So for instance aspirin, the way First Data Bank supplies the data, an example would be aspirin. It can only be either an anti-platelet or an anti-inflammatory, or analgesic or an anti-pyrrhetic(?), when you know it should be all four. So we will have to deal with that, that we have incomplete or we have single hierarchies as sources.
Another issue is that of errors. I guess we are all human so even reference terminologies have mistakes in them.
Violation of principles. In this I refer to the fact that not all vocabularies follow the informatics principle laid out for good controlled medical vocabularies, like meaning less codes, and so on and so forth.
Updates and versions, this refers to the fact that reference terminologies we use have updates and versions, and we have to follow along and make sure that the updates and versions are compatible. In cases of ICD-9-CM and CPT4 it's essential that we keep up with the updates, because they affect reimbursement.
Now operation support logistics refers to the fact that we will have to interact with the source vocabularies we use to get the information we require, as well as to put information back.
Now licensing and cost is something I specifically mention, because it's not so bad really for a vendor. To be frank, vendors will pass the cost along. It's the fact that customers now get hit by the licensing and costs. So how does the dictionary try to solve this? To start with, as I have said before, the dictionary is working product. The source vocabularies we use are not applications per se, so to support our other products, which is the 3M clinical data repository and so on, we have to have a computer application anyway, and that is the dictionary.
So the fun part is how do you incorporate all these source vocabularies in the dictionary to both stick to informatics principles, and be practical and useful for our customers? So our solution is modeled after the UMLS. And that is we provide a cross-reference or map between all the source vocabularies we use.
So we try to provide a cross reference or map between a control vocabulary and a classification scheme, as well as between a reference terminology and an interface terminology, where if the source of a vocabulary is incomplete, we will supplement.
For instance, the aspirin hierarchy problem I referred to. No matter how our source vocabulary changes, it's hierarchy, because that's what we were told. If this one is anti-inflammatory, and this aspirin is more fashionable as an anti-platelet, it will get moved into the hierarchy, and the previous one gets wiped out. Well, in the dictionary we preserve the previous relationship, and just simply add the new one if it's appropriate.
We do not incorporate errors of course. Here is another drug example. Some time ago we saw in one update that dental products were placed in reproductive system agents. After a month of trying to figure out how a dental product could be possibly be used in the reproductive system, we decided it's got to be an error. We feed the information back to our source, and the next month it is correctable. Of course we are not going to put that into the dictionary.
And we would of course take over the operation and support issues for our customers, so we make sure we do the updates and versions, and so on and so forth. And also arrange for licensing and stuff like that.
Then we of course want to work with the standard developing organizations by submitting concepts and terms that are not yet found in the source vocabularies back to the standard developing organizations.
So here is an example, and I would like to walk you through it so you get an idea of what I'm talking about. For instance, we need to interface a customer's legacy lab system to the 3M CDR. The way it works, the dictionary sits in front, if you visualize it that way of the CDR. Nothing gets into the CDR before first going through the dictionary.
So we have to therefore, make sure that all the customers' legacy terms and maybe concepts are in the dictionary or the transaction will just error off and not start. So for lab results, the 3M dictionary uses LOINC. So each LOINC lab result is a concept in the 3M dictionary, with a 3M concept identifier, which you can see is analogous to the UMLS CUI. And the LOINC code, the 1234-5 format is a synonym of that concept. So the concept now has its own 3M ID, as well as a LOINC code.
So you know a legacy system would use its own proprietary interface codes and display names. So to obtain all the required information from the customer to map each of these legacy system name pairs to a LOINC lab result concept that is already in the dictionary. Therefore, the customer's legacy code and name would be the two additional synonyms for that particular concept.
And if we cannot find an existing match, therefore it's not in LOINC yet, then we will create a new concept, a new lab result, give it a 3M ID, and then map the customer's legacy code and name as additional synonyms to that concept. And we will create a LOINC name and submit it to LOINC for review and inclusion in the next version.
This is where LOINC could come and tell us, look, you just missed it. It is actually in LOINC, and so on. And if it's not, then we hope that LOINC would put it in the next version, and therefore assign it a LOINC code. At that point, we will take that new LOINC code, and add it back into the dictionary as the synonym for that concept.
So what is required for coordination among terminologies? From the example before that, you can see that I believe that all of these are required, cross-walks and mappings among terminologies, common definitions of concepts, as well as convergence to a single reference terminology or model.
For this last item I believe that it could be a conceptual convergence rather than a physical one, meaning you can end up with per data area for instance, and not necessarily one for every possible domain in medicine. In fact, I believe that it would be a lot more work, if not impossible to come up with a single physical reference terminology.
The points I would like to make are the following. First, I do not believe that medical informatic principles are the issue here. I'm really quite junior to this, but from what I've seen, this is an area of research that has gone on for quite a while, and we've got all these brilliant minds working on it. And I think the informatics principles are understood, and in most cases adhered to, or at least try to adhere to.
I'm seeing a maturing, if not an emergence of reference terminologies. The market seems to be moving towards de facto standards. For instance, in lab results I don't see anything other than LOINC. It is well known. It seems to be widely used. We certainly use it religiously.
The market is also moving towards coordination, you know LOINC and SNOMED and SNOMED and RECO(?) are just two examples. And so I believe that there is already coordination going on, and of course the government can still promote it by leading by example, for instance. And I believe the government is doing that, in having projects such as the GCPR and the CHCS2.
However, what do I see as the big issue, and not discounting the work that goes on in development and coordination and so on of standards is that we really have to think about the end user. And the 3M HDD, health data dictionary is not an end user. We are just a working product. If you want to, think of it as a middle man. We are not the end user.
The end user is the health care enterprise out there that may be a 100 bed community hospital. What can be done to bridge the gap between the informatics that is going on with development and vocabularies and so on, and the end user who worries more about making the profit, or not losing too much money, getting systems online, just getting information to the clinicians and the administrators.
The biggest problems I have seen based on my experience with our customers, as well as our sales prospects are costs and lack of understanding. They may understand, and there still may be the issue of cost. I mean it is expensive to deal with terminologies.
Setting aside the cost of developing the terminologies, the cost of using the terminologies is significant. Of all our customers and prospects, I've seen only one who has a more or less standard vocabulary in their system, and that I believe is LOINC. Everyone else has legacy terms and codes and so on. Even when vendors, such as a lab system vendor adopt LOINC, those only come out in new systems. All these systems that are already installed in hospitals don't have LOINC. So how do you get them to use LOINC?
So the cost is there. One way or the other, there is just no getting away from it. So first of all, you've got to educate the customers as to why they even want to bother about LOINC. What is it? Why should you care? With an understanding they may say, okay, I will bear the cost. Or they may say, yes, I understand it is very good, but I still cannot afford it.
I just want to stress that focus needs to be placed on paying some attention to the end user, as well as to development. So government funding for research development applications, maybe a coalitions of developers and users are just some ideas I throw out.
One model I want to talk about is LOINC. I mean as you know, LOINC to me appears to be almost a de facto standard. Lots of people know about it. It's one the few standards that our sales prospects will actually ask about. Do you use LOINC?
However, there are costs associated with LOINC. I know it's public domain and free, but it's not really free in the sense that it didn't appear out of thin air. There is still a lot of manpower and money that went into developing it. So it may appear free to the end user, which makes them very happy right now, but will this continue forever? Can this model be applied to other terminologies?
So I'll end here. Thank you very much.
MR. BLAIR: Thank you, Dr. Lau. Am I pronouncing your name correctly?
DR. LAU: Yes, thank you.
MR. BLAIR: And our next testifier, please.
DR. YASNOFF: Jeff, this is Bill Yasnoff. While Dr. Rubertone is re-establishing his online connection, I just want to say something to put his talk in context. We have talked a lot about the benefits of having standards for patient medical record information, particularly the benefits in terms of aggregating data, and looking at population health.
Within DOD there are certain problems of aggregation of information that can be easily overcome; problems that are not overcome in the civilian sector. Because of that, Dr. Rubertone and his colleagues have been able to put together a population health monitoring system which shows in a very concrete way, the types of benefits we have been talking about in a rather abstract way.
So he came to CDC and gave a presentation, and I thought the work group would benefit from seeing this more concrete vision of what these benefits are.
MR. BLAIR: Excellent. Thank you.
DR. YASNOFF: And I think I have talked long enough to allow him to get his online connection back, is that correct?
LTC. RUBERTONE: We're just about there. Thank you.
LTC. RUBERTONE: My name is Mark Rubertone. I'm a preventive medicine physician at the U.S. Army Center for Health Promotion and Preventive Medicine. I'm currently the chief of the Army medical surveillance activity. I'm very pleased to have this opportunity to present to this working group today.
My perspective, as Dr. Yasnoff mentioned, is not so much from the developer of computerized medical record standards, as a developer of a system that capitalizes on pre-existing electronic medical records and standardization, and a developer of an integrated system that uses that information.
What I hope to do today, time and technology cooperating, is to give a functional overview of the Defense Medical Surveillance System, a system that has focused on the concept of medical surveillance decision support within the DOD. I will do a live demonstration of this system. I'm connected over a phone line, and I understand that by taking the phone off the hook in the corner, some people will appreciate that.
I then will turn my attention to the Defense Medical Epidemiology Database. That's our remote access application which is freely downloadable over the Internet, and allows access to the data in our system, all without privacy act data, all without identifiers. The security is a high priority for us in the miliary. And I'll end with a demonstration of DMED.
Just to start with a little bit of a background and timeline, this system really has its roots back in the mid- and late-eighties when the U.S. Army was tasked with tracking the emerging HIV infections within the military. There was a U.S. Army HIV data system back in 1985-1992.
In 1992, we began looking to other diseases of military importance, rather than just HIV, and the design for the Army medical surveillance system began. This system was designated an official military health system in 1994, and with that came some secure funding. That's a real advantage for us in order to accomplish what we have been able to do.
We began to routinely publicize our surveillance data back in 1995. The DMED project, or this remote access application really began its work in 1996. The four services got together to talk about standards, and semantic equivalency of data and the like. Meanwhile, the Army's medical surveillance system in 1997, transitioned to the Defense Medical Surveillance System. This was really key in allowing us to have the kind of standardization across the services that we were looking for with the DMED project.
In 1998, we expanded our data sources to not only include inpatient data, but also ambulatory data, casualty data for active duty, some deployment data, and et cetera. And finally this year we released the latest version, Version 2 of DMED, which I will demonstrate for you.
I usually start with the definition of medical surveillance to give a perspective of where we have built the Defense Medical Surveillance System. As this slide reads, we define medical surveillance as routine, systematic collection, analysis, interpretation, and reporting of standardized population-based data for the purposes of characterizing and encountering medical threats to a populations' health, well being and performance.
The three components of that definition that I want to draw some attention and focus today are the fact that it's routine and systematically collected. Without the routine and standard data that already pre-exists in the military within the DOD, we wouldn't be able to create this system.
The second is that there is a component of analysis, interpretation, and reporting, because the data warehouse mentality wouldn't go very far, and there are not many users who would benefit. So getting the data back out to those who are making decisions and making policy from this data is critical.
The last concept is the population-based data. This differs slightly from the concept of a computerized patient record in that our focus, our population are not patients. Our population are men and women who have served in the active duty and reserve component of the services for the last 10 or so years. When they are patients, we do capture information on them, but we maintain the focus on the population at risk to being patients or being at risk for diseases and injury. That will be a little clearer later on.
I won't go over this slide. I know it's busy. It basically just shows that there is a routine and systematic data collection within the military. Again, we benefit from that.
I'll instead kind of spend some time on this slide, which is the concept, to show that different types of tables that are now in the Defense Medical Surveillance System. These are just the major tables listed here in the first column, the source and the frequency with which we receive the data, which typically is monthly, but in some cases is daily, weekly, or even annually for certain data sources.
As this table demonstrates we are currently tracking 6.5 million individuals who have served in the active duty or reserve components since January 1990. Along with those 6.5 million individuals, we have another 55 million rows of demographic information that has created our longitudinal record over time. This is very critical when we go to do cohort studies, looking backwards in time, and going forward now, looking at what happened to a particular group as compared to a different group, and exposed or unexposed or et cetera.
We have as much data as is electronically collected and available from deployments, but as many know, the DOD suffered from the fact that records were not very well codified during the Persian Gulf War. After that, there have been a number of efforts to electronically codify the inpatient and outpatient records from various deployments, and we're currently receiving inpatient data from the Bosnia theater, and outpatient data from the theater in Southwest Asia.
We do have the standard inpatient data record, with 1.7 million hospitalizations amongst these service members. Another database, our ambulatory data really just came online back in 1996, and since that time we have already collected over 26 million ambulatory clinic visits on this population.
One important thing to point out is the two at the bottom, which are still Army only systems. That's reportable events, and a health risk appraisal, or a behavioral risk factors type of survey. Even though we have the luxury of having a lot of data which is standardized, and semantically equivalent, there is some that is not. We're working aggressively with the services, very cooperatively to work towards the point where we can have data integrated into the system.
The next two slides I will go over pretty quickly. They are just examples of our medical surveillance monthly report, where we publish the data similar to the CDC morbidity and mortality weekly report. This slide I'm going to kind of build. This really describes the longitudinal nature of the Defense Medical Surveillance System. As it shows, it is focused on active service members from pre-induction to post-discharge.
It begins when someone comes into the military entrance processing station as a civilian applicant for military service. We capture that complete record, their home of record information, demographic information, whether there was a medical failure at the time that coming them from coming out to military service, et cetera.
We also at that time do an HIV test. One of the requirements for service in the military is you be HIV-negative upon entry. If you are diagnosed while on active duty, then you are not kicked out. You are rather just judged like anyone else as to whether you can physically remain in the military because of your condition.
At that time, the HIV test that is done is sent to our central DOD serum repository. We've got over 24 million banked leftover serum in that repository here in Rockville, Maryland.
The next thing that typically happens when someone comes on the military is they are given an assignment. We get assignment information on a monthly basis from the Defense Manpower Data Center. This is our source of population data once someone is in the military. This, as I've said, over time has created this longitudinal database.
We get deployment information, again from DMDC in terms of who is deployed, when and where. We also get medical type of information from that deployed theater. Once this is created and we have this population database, we tend to add other things that are usually already available in electronic form and that have been standardized. So in some ways we benefit from the previous work of others that have lead to the standardization of data.
We have the inpatient hospitalizations, as I mentioned, the ambulatory data. We have a method for collecting reportable diseases, where different facilities transmit through each service, reportable disease information, either on a daily or a weekly basis.
We have the health risk assessments, which is a behavioral risk factor survey that asks about seat belt usage, smoking history, breast and testicular self-examination, et cetera.
We do get information specifically for deployments, pre- and post-deployment specimens, and also surveys asking about the health prior to and after returning from a deployed situation.
We have just recently added casualty data to our system, tracking the 20,000 deaths that have occurred in active duty military over the last 15 years.
Lastly, we have a good deal of environmental exposure data, but it's on this slide with a dashed line, because it is not currently part of the Defense Medical Surveillance System. That data is typically generated at the time and place and a type of sample, and it is not linked to a Social Security number, so we can't link it to an individual.
There are some efforts underway to know who is where and when on the ground during deployments so that we then could link the environmental exposure data to individuals. But we don't have personal monitors, and we don't have ways to capture this data at an individual level.
I apologize for speaking so quickly, but I wanted to get to this point, which is actually where I will demonstrate the Defense Medical Surveillance System. I have it running in the background on this laptop. It is connected back to the server, which is on the Walter Reed Campus here in Washington, DC at the Army medical surveillance activity. I am just connected over a simple modem line, so some of the response time is slower obviously than what we would have if we do this live.
A place where I would like to start is with what we call our data dictionary. Again, you will see a lot of the same main tables that I have described on previous slides. But since I'm doing this live now, we can actually look up information. For example, if I double click on person, you can see that there are 6.5 million individuals we're tracking in the system. These are the variables of those individuals that don't change over time for the most part -- their race/ethnic, sex, Social Security number, et cetera. Things do change, but for the most part, these are unchangeable variables.
If I just double click on this race/ethnic variable, you can see that this is the current racial or ethnic demographic background of the 6.5 million individuals on active duty and the reserve component. I can do that for any of these variables here.
I mentioned this DMOG or demographic table that has 55 million rows of information. As this information changes, somebody's primary military occupational specialty or their unit or their unit location, zip code, education level, we capture that on a monthly basis. So we have constructed this population longitudinal database.
Inpatient data, as it's opening up, 1.7 million rows of inpatient data. This is already coded for us by the military treatment facilities, and collected in a central location. We capitalize on that by having a feed once a month from that system into our system. We then integrate it together.
That's not to say that we don't have to deal with data standardization issues and common data dictionary issues. We do, because we collect data from over 25 different sources, so we do have to map it together, and have our own common data dictionary. But for the most part, standardization of hospitalizations for example, has already been accomplished by the DOD, and we do capitalize on that.
This has just, as you can see, number of bed days, clinic service, up to eight different ICD-9 clinical modification diagnosis codes, and some extenders that are important to the military, procedure codes, and the like. There's about 104 different variables in the inpatient record.
In the ambulatory record, which would be called a SADR(?), again, since January 1996, over 26 million ambulatory clinic visits. Again, you can see the types of information that is coded. If I click on this disposition code, we can see actually what happened to those individuals. The vast majority were released without any limitation, but you can see those that were released with some kind of work duty limitation, some that were released to home with quarters, some that were admitted, and there are those that actually never left the clinic. They died either from an MI or some condition in an ER setting, et cetera, but that is captured as well.
I'm going to move on in the interest of time, and just give one quick example before I go on to our remote access application, and that is what we call the deployment pre- and post-analysis. It is really for demonstration purposes. It's not the way we do our analysis, but you will see what I mean.
This is just the ICD-9 tree. It can be opened and gone down to the four digit or five digit level. There's nothing too fancy about that. If I choose for example, infectious and parasitic diseases, and if I go over here to our deployments and choose let's say Somalia. Let's say I'm interested in what happened to the individuals who went to Somalia in this category of disease.
I can tell you that we have already prearranged a control group with this group of people who deployed. So a group of who didn't deploy we have already pre-assigned random matched on age, sex, race, ethnic, whatever the variables. You can do that depending on the actual study and intention of the study. But we have a pre-defined control group.
But otherwise when I hit graph here, this will search onto the inpatient record files and find all those hospitalizations that occurred in the year prior to deployment for those who were deployed, compared to those who were not, and in the year following deployment. As you can see, and as you might expect, infectious and parasitic diseases would go up after a deployment to Somalia.
Well, if I double click on this green bar here that shows about 130 hospitalizations, we can actually look at the records, again without any privacy act data for demonstration purposes. But you can see, and I'll sort this by description, the number of vivax malaria cases, chicken pox that were admitted during deployments, unspecified malaria. There was a tick borne fever, et cetera.
I can look also at the control group that wasn't deployed, and say what where they admitted for back home. Here is some Reiter's(?) disease, sarcoidosis, toxoplasmosis, et cetera.
This just shows that in order to accomplish this, we have had to integrate not only the personnel records that said someone was deployed, but their medical record. And the fact that we are able to do this really live, as was just mentioned before, is a tribute to the information technology that exists today, the relational databases that allow this kind of database optimization.
I'm going to move on. Before I do, I apologize. I forgot. I usually look up my record just to show an example of this longitudinal record. Sometimes it is easier once it's seen. This just allows me to choose my personnel records. I won't choose my inpatient or outpatient, deployment, or reportable events records right now.
By typing in my Social Security number I can quickly search amongst the 6.5 million individuals for my record, and search across the 56 million rows of demographic information for my records. And as you can see, even though we are on a slow phone line, this comes back pretty quickly. There is my record. There I'm getting my unchangeable information. This is my longitudinal record here, showing when I entered the military, when I got married, when I was promoted over time, all the way down to my last record, my current assignment, et cetera.
We don't use this again, to do our analysis, but it kind of gives an example of how we keep the data organized in this longitudinal fashion.
I'm going to move on now to the next part of presentation, and that is the Defense Medical Epidemiology Database, called DMED. This is a remote access via the Internet. It's just a subset of the data that is contained within the Defense Medical Surveillance System. There are no personal identifiers or any links to any specific individuals in this system, because it is distributed to those within the military, and others who have a legitimate, authorized access to military data. It is user name and password controlled. This software is distributed from our Website at AMSA.
What I'm going to do is very quickly do these following four examples using the DMED system. As you can see, I'm going to look at heat stroke hospitalization rates at Ft. Benning, Georgia; reported cases of vivax malaria from Korea; the top ten causes of mental health visits in the Air Force; and tuberculosis hospitalizations, U.S. military 1990-98.
As I switch screens here, any of you who have done any kind of studies or analysis of this nature, can think of how long it would take you to look up this information on any group or any population of individuals. I'll start with the first one, which is the heat stroke rates at Ft. Benning, Georgia. This application again, is running over the Internet through the telephone line. It allows me to choose a detailed query on hospitalizations. I don't remember the code for heat stroke, so I can look it up, and there it is, 992.0 with the ICD-9 code.
Under strata I'm interested only in the Army, and only at Ft. Benning, Georgia. There are over 400 different sites that we can choose to look at these queries, or look at the entire military, or an entire service within the military at one time. But this allows me to look at Army individuals who are stationed at Ft. Benning, Georgia. I'll just look at heat stroke calendar year, broken down by age.
If I submit this query, as it is running I will say that our own benchmark for this application is that we don't want anyone to wait more than 30 seconds for the result. We figure if you wait more than 30 seconds, you will get bored. You will want something else. So as you can see, that took about 10 seconds to come back.
This shows the 67 cases of heat stroke that were admitted at Ft. Benning, Georgia over the last few years. If we look at person years, this describes how many people, roughly 18,000-19,000 individuals that have been assigned to Ft. Benning, Georgia over time. We can look at the rate of heat stroke, or we can look at a line chart to actually see that it is possible in the less than 20 year olds, heat stroke is on the rise.
Recently we just did have some admissions for heat stroke that prompted us to do this query. But this is just an example of a number of different queries that can be done.
The next one, reported cases of vivax malaria in Korea, again we would go to a detailed query. This time rather than hospitalizations or ambulatory, we'll just go right to reportable events. I'll go down here to the vivax malaria. Again, we're interested in the Army, and we're interested in Korea. So I can choose any state or country as a whole here.
And again, I'll submit this query here. There has been a resurgence of vivax malaria in Korea, and it's one of the things that we have seen through our surveillance efforts, increasing numbers of reported cases. You can see there were none in 1995; 8 in 1996; 17 in 1997; and 10 in 1998. We don't have 1999 data on here just yet, because it's not a complete calendar year.
I'll skip over the next one, but in the interest of time I'll just go to the last, which is tuberculosis hospitalizations U.S. military 1990-98. The reason I chose this one is because within the last month I was reading an MMWR article on tuberculosis across the country. It happened to say what the Healthy People 2000 rate for TB was, and that was 3.5 per 100,000.
So if I look at hospitalizations again, search for tuberculosis, go to pulmonary tuberculosis, and keep all the services, keep everything else here. I could point out that if was interested in males under the age of 30, or enlisted males under the age of 30, I could do that. But for now I'm just going to keep everything selected as all.
I'll just do this by -- we'll display it with the X axis being the calendar year and the Y axis being rate, but divided out by race, and I will submit this query. I can say this, I actually did this in my office when I read that article in the MMWR to see what the rates were across the military.
This again just starts off with the counts of pulmonary tuberculosis. Person years says exactly what the denominator we are looking at, roughly 2 million active duty individuals in 1990, down to about 1.4 million active duty individuals in 1998. We can look at the rate. These are small numbers, so I look at it per 100,000 rather than per 1,000.
I can see already that in whites and blacks we are below the 3.5 per 100,000 threshold for Healthy People. However, in the other group, which includes Hispanics, Asian, Pacific Islanders, et cetera, they are still higher at 3.92. If we look at the line chart we can see that information. Even though it's coming down, it still may be a group that can be focused on.
I'll do one other type of query, just to show our ambulatory data, since we have such a wealth of ambulatory data. If I was interested in the Air Force, and if I wanted to look at ambulatory things for the respiratory system. We are coming up to the cold weather season. That's going to be an issue for the Air Force, as it is for the Army. I can submit this.
This is a little bit different type of a query in that you don't start with the disease or injury of interest, you start with the population. You say what was the top causes of ambulatory clinic visit among this group. You can see 117,000 clinic for URI, upper respiratory infection. And then allergic rhinitis, acute sinusitis, et cetera, all the way down to deviated nasal septum.
I think I will end there and wait for any questions at the end.
MR. BLAIR: Thank you all for very informative testimony. Let's open it up for questions. Do we have questions from our committee members or the staff? Dr. Cohn?
DR. COHN: I'll start off here. First of all, I want to thank all of the panelists. It's been a tremendously interesting set of presentations. I actually wanted to start with a couple of questions of Dr. Lau. I thought your discussion as a real life user of terminologies and trying to create a data dictionary were fascinating.
I actually had two questions for you. They both relate to the overall issues of terminologies. One has to do with your experience and any issues you might have with the overall concept of licensing, and what your experience has been with that.
The other question had to do with your comments about reference terminologies. I was wondering as you worked in these areas are there any holes or conflicts or whatever you notice in the sort of terrain of reference terminologies as you define them?
DR. LAU: Well, first of all, licensing and cost. We found our customers generally don't mind the licensing and cost that goes into the dictionary in the sense that they expect whatever we charge them for the dictionary will include whatever required licensing fees for SNOMED for instance. So they do expect to contribute a little bit. They don't expect to carry the whole licensing fee, obviously, but contribute a little bit.
However, the problem seems to come when you start telling them okay on top of this one time sort of fee, now depending on the number of users, you also have to pay SNOMED this amount. That is when they start balking. That was a somewhat gray area, because the argument from the customer is well, I'm sending an actual SNOMED code. So why do I still have to pay a per use charge? I have already paid a part of your license for SNOMED.
So it's the same for First Data Bank and stuff like that. For us, maybe because of reimbursement, they don't seem to have that problem with CPT4. So that's about licensing and cost.
Now reference terminologies. Well, the customers don't really worry very much about whether there are holes in the reference terminology. In a way I guess that's why in my presentation I stressed so much the end user viewpoint, because if you think about it, it's really quite a compliment. Customers out there expect that the informatics community will just get it right. They don't want to hear, oh, what's the problem ICD-9 trying to work with SNOMED. They're not interested. They say, it's your job to just get it right.
What they care about is as long as their interface terminologies, the terms they want to use, the codes they want to use, they can continue to use it. Again, they see it as our job to go fix it.
So yes, I do some holes, some incompleteness and I referred to that, but I personally don't see it as a big issue, because I think things will just continue to improve and mature for reference terminologies. The part I don't see really going away is the gap between interface terminology and reference terminologies because until and unless all legacy systems are replaced, and maybe that will never happen, that will always occur.
And maybe even when you have all systems having standard codes, you will still come across people who want their own acronyms, customers who will make their own local drug compounds that will never be found in any pharmaceutical database, and issues like that.
DR. COHN: Can I follow-up on that one? Thank you for your comments, and I just had one follow-up relating specific to reference terminology, and then I'll let Dr. McDonald follow-up. You had mentioned SNOMED and LOINC as two reference terminologies. What you using for drug terminology as the reference terminology, for the drug area?
DR. LAU: Well, we licensed the pharmaceutical database from First Data Bank. So it does have NDCs. Then the rest of information are propriety from First Data Bank. They are drug classes, they are hierarchies, they are ingredients and form and route information, and so on. The NDC part is not proprietary, obviously. The links will be.
DR. MC DONALD: Just a comment about the CPT versus SNOMED. My understanding is the licensing structures are different, and that CPT is licensed, the count of users are those who are actually entering in the codes in the medical records rooms. So it's a more constrained list. It's not the whole environment of people who might be using any of your information system. If someone on a ward using CPT4 -- this is my understanding -- they don't charge for that. It's the actual people who are doing the coding.
MR. BLAIR: Do we have other questions?
DR. MC DONALD: I had a question, yes. Your system you showed, you were talking about numbers of 27 million rows. It was spectacular response times. I just wonder if there is some trick behind, or what the system was that was doing such a fast job? Had it been presearched or pre-fetched?
LTC. RUBERTONE: No, we didn't, and I appreciate the question. This data and the types of queries that did has just been optimized in Oracle to retrieve that kind of speed. So when I did a retrieval of the top ten causes of ambulatory visits, it did search through all 26 million rows in the Air Force, and had them summarize just the top 10.
We have been able to do some tricks in order to optimize for that kind of speedy response, but there is no trick. I do appreciate the question, because I've been in your seat many times looking at individuals with just slide shows telling about their system. That's why I try to do a live demonstration. If you wish I could anything, pull up any different group or ICD-9 code and get the same type of response time.
DR. MC DONALD: What kind of machine is it that's behind it?
LTC. RUBERTONE: It's what's called a super mini-computer by Hewlett-Packard. It's got four processors in it. It's the size of big desk top. These things have just continued to amaze us with their speed and decreased size, et cetera.
MR. BLAIR: Other questions?
DR. ZUBELDIA: There has been an interesting dynamics here. Helene was saying that the goal was to have a standard terminology, and to try to get rid of these differences between UB92, X12, HL7, all these codes for marital relationship being different. Whereas, Dr. Lau was saying that this is just interface terminology, and we'll have to live with it. We are building a way to live with it, whereas we will need a reference terminology, as long as we can map from the interference to well, some sort of reference terminology. They don't have to be one in the same.
And I kind of agree with that, because I don't think we will ever get X12 to change all their codes to HL7, or HL7 to change all their codes to X12 codes. I don't think that is going to happen. But how do you deal with the problem where there is not a one-to-one map? For instance, I'm thinking of the difference between the relationship between the patient and the insured.
In the NSF for instance, there are four codes, 1, 2, 3, 4, self, spouse, child, and other. In X12 there are 20-something codes. And when you go to specify a child, you cannot just say child. You have to say whether it's the dependent child, or whatever the relationship is. There are over 20 codes. How do you do that mapping? Is that mapping even possible sometimes?
DR. LAU: It is still one-to-one, but not in the way you think in the sense that for the standard you referred to when there is only a child, and the code for child will be mapped to that, right? And another standard doesn't necessarily have child. It has daughter or son, and then stepdaughter, stepson or whatever variation you have. Then those codes would be mapped to those concepts. Then you would have relationship between child and those concepts. So you are saying that daughter is a child. A son is a child, and so on.
So the interface codes do not map directly. The interface codes map to concepts, and the concepts are related. So it's the same with the composition/decomposition where you have legacy systems that will send us three codes, left, upper, and arm. Another system, another customer sends one code left upper arm. To be able to know that when you come time to do your population-based queries or decision support, that the three in one case is the same as one in the other case. So it's two relationships, not one-to-one code map.
MR. BLAIR: Other questions? Mike, please.
DR. FITZMAURICE: Yes, I wanted to ask Helene if she would take us through the different models for computer-based patient record, and where you store the data within the computer-based patient record. How you frame it so that you can search and pull the data out. How have vendors responded to E13.84? Do they use this? Does it help them with their modeling? Is it conceptual and theoretical, but has not been practically adopted or used yet?
MS. GUILFOY: As far as the vendors go, I am not familiar with a particular vendor that has used it for modeling. I used it when I was developing my concepts if you will for our clinical documentation model. But I'm not a vendor. I was using it as a user working with four different hospitals, to be able to put their clinical documentation tool together. To the best of my knowledge, it has not been used by a vendor.
DR. FITZMAURICE: Does it have the ability that if I want to get a particular lab test, that I can go to the section in E13.84 and pull lab test, and it will have a string to laboratory, a string to maybe a test performed on the floor, to a string wherever that particular kind of test is found, and pull it out and give it me, or is that a functional operation that would be in an implementation of the system, not in the 13.84 standard itself?
MS. GUILFOY: It would be the representation. It's not -- 13.84 is not a technology if you will. It's not Mark's example. It's an overall conceptual model of the way a computer-based patient record would be structured. But to actualize the concepts that are within 13.84, you would be able to do exactly what you are talking about.
DR. ZUBELDIA: I have kind of a follow-up question on that. Help me understand a little better about 13.84. Is that a model for the medical record itself, or for the transmission of the medical record?
MS. GUILFOY: It's the medical record itself, not the transmission. It's not a technology format. It's what you need to have in an electronic health record for patient medical record information.
DR. ZUBELDIA: How does it map to the transmission method? Does it map to HL7?
MS. GUILFOY: There is not any expectation that it would map to HL7. It's a concept model. It's not a technology model. It's much like the NPRM for the security standard. There was every attempt to make that technology independent, so that the individual user could use their own technology to implement that particular concept.
DR. ZUBELDIA: Once you implement the concept, and you want to transmit that medical record somewhere, can you do it with HL7?
MS. GUILFOY: Sure.
DR. ZUBELDIA: So it is mappable to transmission?
MS. GUILFOY: Exactly. And that's part of the goal of E31, is to be able to have these standards be proof. Say that this will work.
DR. COHN: Helene, I actually wanted to ask a follow-up, and I think Dr. McDonald it sounds like has one also. You just addressed a question from Kepa about its implementation. I think you had commented that no vendor to your knowledge has actually implemented this. I just wanted to follow-up just for my own clarification and understanding. The 13.84 has been around for some number of years. And can you perhaps explain or --
MS. GUILFOY: Why doesn't the vendor use it?
DR. COHN: Why it has not been implemented. Just your thoughts on this one.
MS. GUILFOY: My thoughts on it is that it is conceptual. It is not something the vendor would take and go out and develop a database based on the data elements that are within 13.84. They would take the ideas that are in 13.84 and say if we are going to develop an electronic health record, these are the elements that we want to have, and this is the structure that we want to have for an electronic health record.
Remember, the title of it is concept and structure. It is not record layout, which is what the vendor would need to have in order to implement an electronic health record. So if you looked at the two sides of that coin, that you have the ideas of what you need to have, what that electronic health record needs to contain, if you take that concept, that idea, and you wrap your technology around that to make it a practical solution.
DR. MC DONALD: I was going to extend on that. I was involved in the writing of 13.84, and the --
MS. GUILFOY: Sure, very much involved.
DR. MC DONALD: At the very beginning it was more a description that came from the perspective of the paper records from the medical record department saying these are all the things, and trying to categorize and inventory all the things in it. And then there was sort of mixed interest from some players to be more detailed, more like a data structure.
Actually, HL7 donated two or three segments, so that those segments look alike, at least at that point in time when it froze I think. There is some schizophrenia. It wasn't quite sure what it wanted to be I think at that time.
MS. GUILFOY: I think when Clem was involved the title of it was description of computer-based patient record. That evolution has changed it to what it's called today. I want to point out that it's a living document. As all of our understanding of patient medical record information is, it needs to be a living document.
Medicine, the practice of health care is continuing to change. It is evolutionary. So we need to be able to have our understandings of what we need to contain in an electronic health record needs to be living also, and needs to reflect the practice patterns of the health care provider, as well as the patient.
MR. BLAIR: Let me ask a question at this point. Dr. Lau, that was a wonderful list that you had there of the different terminologies that are used within your clinical data repository at 3M. And included in the list was both SNOMED-RT and the UMLS. In particular, you indicated that you did some references to the CUI, the concept identifier of UMLS.
Could you help me understand a little bit the different roles that the CUI and UMLS are playing as a concept unit identifier, versus those that are within SNOMED-RT, why do you have both? And what is the difference between the applications or concepts that are being related to each?
DR. LAU: Well, we started off from a slightly different point of view actually. We realized from our customers that what they really wanted is to see their list of diagnosis of problems. Then they want to go get the UMLS CUI or the SNOMED code for each of them. So the requirement from the customers is not for us to say choose between SNOMED and UMLS and pick one of them, and dump it onto the dictionary. Not at all. They are not interested in whether we have the whole of SNOMED or UMLS or how we reconcile between them.
They just want their list of diagnoses, and each with an ICD-9 code, a UMLS code, and SNOMED. So we really use SNOMED a bit more than we use UMLS in a sense. The first thing we look is in SNOMED, and we get the SNOMED code. Then we look in UMLS and we try to find a UMLS code. Both of them are very useful, because there are times when they agree with each other, even though SNOMED, an older version is incorporated in UMLS.
Often I will remember an example, and then we go and check to alternative sources, textbooks, ask some physicians to reconcile between them. Basically, at the end we have to make a decision and decide which is right or which is wrong. Because remember in the dictionary each concept has its own 3M ID, then all these other codes are just synonyms. That's how we end up reconciling them. Essentially, you have to make a judgment call when they don't agree with each other.
MR. BLAIR: Okay, other questions?
DR. COHN: Actually, I have a question for Dr. Rubertone. Thank you very much for a fascinating presentation. I'm trying to think in my own world, which is Kaiser Permanente, you sound like you have the penultimate employee system, as best I can tell. Could you comment on that?
LTC. RUBERTONE: There's not as close a connection as you might think. We both use the same databases that are developed. So the composite health care system to CHCS2 and the work on getting a computerized patient medical record that has been seamlessly transitioned to the VA, the Indian Health Service uses the same data input.
We found that because of our specific needs for maintaining the data as a longitudinal database -- and I know that the government computerized patient record talks about a solider lifecycle record. Well, we also have that, but not from the perspective of patient care and medical records, but from the perspective of the population.
Though we have not duplicated what they are doing, but we have done it independently, because we really have a need to look at the experiences of this population over time independent of actual health care visits. We get the inpatient and outpatient data and then apply that, but it's a slightly different perspective. I would say it's more from an epidemiologic perspective that we have created this.
So we don't need to, because of our mission, actually work very closely, although we benefit very much from the work that they are doing to standardize the medical records. Does that answer your question?
DR. COHN: Well, you almost do, because I saw you were talking about two different things. One was the Defense Medical Epidemiology Database, which I absolutely agree is as you just described it. The Defense Medical Surveillance System sounds like you had sort of a summary record in a longitudinal fashion, which would be what I would think somebody who is retiring would want to have follow them across. This is somebody who is not in the military, so I may not truly understand.
LTC. RUBERTONE: Right. I guess it's the objective of the different systems that might differ a little bit. I'll give one example. A number of years ago the Air Force was concerned about female fuel handlers and whether there was an increased risk of ectopic pregnancy among those individuals.
Well, if you only had the computerized patient record available, you would be able to look at the cases of ectopic pregnancy, be able to maybe look at the occupational specialties of those individuals, and work from that direction.
The way we were able to answer the question is we constructed a cohort of all female fuel handlers over time, calculated their person time, compared them to the rest of the women in the Air Force who were not fuel handlers, and kind of went forward in a cohort fashion, looking for then endpoints of ectopic pregnancy. You couldn't do that with just the computerized patient medical record. You would need the population-based record.
So I think it's the objective that we had in mind as to how the systems were developed. You're right, there seems to be a lot of overlap. And for my budget I have to explain why there is not complete overlap. But there is not to those of us who understand the different purposes of the system.
MR. BLAIR: One last question. Anyone?
DR. FITZMAURICE: I've got one.
MR. BLAIR: Michael.
DR. FITZMAURICE: I guess to Helene and to Dr. Lau as well. I enjoyed all the presentations very much. They were very good. We have heard before that most vendors have their own data models, their own information models. I want to ask is there a public domain data and/or information model to which vendors can refer, or is it true that each of them make up their own and treat it as proprietary information? Would a public domain model be of use? Would it make sense?
I know at least for my purposes when I tried to explain what data modeling is, information modeling is, why you need to have it to people who don't think in those terms, they say, well, does one exist? Why is it that we do need it? Why hasn't it come up before now?
So is there a public domain model that does exist? Do vendors just do their own and keep it to themselves? Would be it worthwhile constructing a public domain model? Or would it so be non-applicable to any real problem unless it got specific, that it's not work the cost for the government to investigate that? What do you think?
MS. GUILFOY: Well, the ASTM standards -- in order to become a member of ASTM, you pay $65 a year. As Clem told me probably ten years ago, that's the best deal on the planet. For your $65 you get access to every single standard there is within ASTM. So you would have access to E13.84 data model for your $65. You would also have access to 16.33 and 17.44, and I can go on naming numbers, but I would go crazy.
That's about as close as we get to a non-proprietary system, even though it is somewhat proprietary for $65. For my own purpose, I would love to see vendors adopt a standardized data model in constructing their computer-based patient records. Do I think that will happen in my lifetime? Lee, you answer it.
DR. LAU: I was just telling her she's too young, not to worry.
Well, first of all I would like to differentiate between an actual information model versus database schema, because not every vendor has both. Second, I certainly don't think there are any public domains out there. The closest thing the vendors get to sharing is just to insure that their information will support the messaging standards like HL7.
So it's kind of like well, if my model will work with HL7 messages, and your model works with HL7 messages, so without knowing what our models are, we are kind of compatible. But that is really you know, extremely vague.
I know 3M would certainly be interested in supporting and exploring this kind of value, because even if you don't agree on a common model or a single model, at least if you know what all the models are, again, you can be comparable. It's like what I said in the presentation. You don't have to be identical, you just have to know what exactly each other is talking about.
DR. FITZMAURICE: But wouldn't it be hard then for the government to build a library, because it would say essentially give me something you spent $1-10 million to build, and put it in the public domain, and you and you and you -- it would be something like maybe a UMLS. Once you see somebody else's you've got it. It's not a matter of licensing.
MR. MAYES: I would just like to make a quick comment to that, Mike, because an information model has, depending on what methodology you use, has both entities and the relationships between those entities. And I think one could go partway, a great way partway, even if you were to only agree on common definitions of the entities. The relationships are probably defined specifically or locally by the context in which you are applying the model.
You wouldn't necessarily have to expose you entire -- one could argue that the relationships that are actually the value-added within a particular system. So you might not have to expose your entire model, but you could try to come to a common definition at least of the concepts that are represented within a model. It might be a halfway way of doing that, that would still add a great deal of value.
MR. BLAIR: At this point we will take our 15 minute break. We will reconvene at 10:35 a.m.
[Brief recess.]
MR. BLAIR: In the tradition of the CPR Work Group, after we have listened to a day and a half of testimony, we try to make sure that we capture all of your thoughts with respect to what you have learned, and what are the important issues or observations. I think, Mike, you are prepared and ready to take notes.
DR. FITZMAURICE: Indeed I am, Jeff. And Margaret too is linking up with the computer and the projector so that you'll have two different viewpoints.
MR. BLAIR: You notice that on our schedule we are showing that we will be going to 1:45 p.m., which we can. Simon pointed out that if we are going to be losing a good part of the folks after lunch, that's a consideration. So maybe I would ask the question now, how many folks would not be here after lunch?
DR. ZUBELDIA: I won't.
MR. BLAIR: We're going to lose Kepa. Who else? Everyone else will be with us?
DR. LAU: Well, I'll be gone, but I'm not with the work group.
DR. COHN: I guess I'm going to suggest since we are going to lose Kepa probably around 12:30 p.m. it looks like based on his schedule, that we should potentially delay lunch until around 12:30 p.m., and see where we are.
MR. BLAIR: So we should work straight through until 12:30 p.m. then? All right. Now essentially what we will do for this next 30 or 45 minutes, depending on how long it takes to capture your thoughts and ideas, we'll do that. And then after that we're going to be turning it back to Margaret Amatayakul, who will take us through trying to pull together and capture issues and observations relative to the things that would be prepared for the final report.
So at this point it's an open forum here. We have some just absolutely great presentations yesterday and today. Are there some key observations, key points? Simon, maybe I could ask you to kind of help, because who is obviously ready to make a comment here.
DR. COHN: Well, maybe I should just comment from my notes that I've taken over the last two days, which I will give a copy to Dr. Fitzmaurice, as well as to Margaret, just because we make copies of the disks or whatever. Just some random thoughts that I had from our speakers yesterday.
Included I think from one of our speakers, the issue that at least from one testifier's perception the key issue was there were not enough physicians or providers who actually are plugged into the environment. Some of them have just billing systems, and some of them don't even have that. Sort of the recognition that one of the key areas that we need to be both aware of in dealing with this whole issue of trying to come up with incentives or otherwise to get more providers plugged in.
At least to that one testifier I think that whole issue of incentives was viewed as a national issue, as opposed to a payer/individual provider issue. So I think we heard that.
MR. BLAIR: By plugged in you are meaning to get them to move towards electronic patient medical record information?
DR. COHN: Yes. I think I would have to go back and look at the specific testimony to I think identify best what the concept of plugged in is, and Mike may have some views. But I think it had to do with as we look back to the HIPAA legislation, really what we are talking about is just not standards, we're talking about administrative simplification, and decreasing costs, and increasing the quality of care in America.
If all we are doing is promoting standards without a context of increased computerization, we are probably not fulfilling those requirements. At least that's how I sort of synthesized those comments. I see some people nodding around the table about that.
Mike, did you have a comment?
DR. FITZMAURICE: I would like to take the comment and say that it's not just increased computerization, but also increased communication. I heard Aetna, I heard MedicaLogic say that they wanted to have computers on doctors' desks not because they wanted to computerize the patient record so much as they wanted to be able to communicate changes in guidelines, changes in coverage, changes in benefits. They wanted these doctors to get decision support when they ordered drugs, and all of this to improve the quality of care, to hold down the costs of care.
I didn't hear very much discussion of increasing access, but two of out three ain't bad.
MR. BLAIR: I have a little bit of concern about adding that additional step in the sense that while I share in the view that computer-based patient records will provide a great deal of benefits and fit in with the national health information infrastructure, so it isn't the goal that I'm concerned about. Right now in the law, the mission that we picked up for our work group is to study and recommend uniform data standards for patient medical record information and electronic exchange of that information.
I think that's with the understanding that that will provide the information infrastructure that would enable and facilitate the development and implementation of computer-based patient records. I think the separation might be helpful for our work group from the standpoint that we have also had testimony which expressed concern by some that we would be recommending explicitly use and implementation of computer-based patient records.
DR. COHN: Jeff, can I break in here? Because I don't know that anyone in any of our conversation has mentioned computer-based patient records. I think we have talked about physicians being plugged in. We talked about communication, which I don't know -- I think you are jumping to the computer-based patient record paradigm.
MR. MAYES: I actually was going to make exactly the same comment. In fact, I think what was interesting was the explicit separation of those two concepts if you will. Of the idea that I at least I heard from a number of places that it's the communication aspects and sharing the information, rather than the underlying local system or structure of the local system.
DR. COHN: I think we're in sync on it.
MR. MAYES: One other comment I would like to make is was very struck by Rick Peters' presentation. I think that we go forward at our peril if we do not recognize some of the things that he pointed out, particularly who is actually driving the creation of these new systems? Well, if we are to believe what Rick told us, and I think there is certainly enough evidence from the financial pages of the newspapers to do so, it is not a -- I don't want to characterize it as not well reasoned.
It's not the medical profession that is sitting down, or even the health care profession in general that is sort of sitting down. The old, established companies in this field that are evolutionarily if you will, moving forward. It sounds like there is a great deal of impetus from the venture capital world, who, as I think a couple of people pointed out, don't come from health care. They come from venture capital. They are looking for where they are going to get return on investment.
I'm not sure how that dynamic is going to work out, but I think to not recognize that there is this huge chunk of this whole process that we have really not addressed at all up to this point. We have acted as if somehow the health care profession and those intimately involved, or the health care HIS-type vendors that are defining all of this and moving it forward.
I think while we certainly are doing that, there is this other very large piece that we have not included, at least up until now in our kind of deliberations or thinking.
DR. MC DONALD: It is true that there are large capitalizations, but I don't think I would bet my life or my fiscal future on some of these extraordinarily ballooned capitalizations. There are not a lot of people working at it in those parts. No, I've had a number of employees, just a tiny fraction that's in the traditional industry.
MR. MAYES: But companies are impacted by the flows of capital.
DR. MC DONALD: Oh, no doubt.
MR. MAYES: But whether or not these are going to be the companies of the future, we need to recognize that there is a fairly significant influence that we have not really discussed in any detail.
DR. FERRANS: I will certainly agree with your point that we do need to take this into account that there are a lot of new players here. I will give you my specific concern. I have been watching this very closely. The specific concern is this. There are a number of these companies, and whether they come from the HIS world, I don't think the fact that they don't come from the HIS world is necessarily a bad thing I think for reasons that Rick has pointed out.
I will say that a number of them do have business models that base a significant amount of their revenue of the reselling of data. This is an area that is going to have to be looked at. I think that that is one of the concerns, number one.
Number two, privacy, security, confidentiality, some of those issues and the data integrity and quality issues have not been worked out, since there aren't very many standards there.
What I did want to say back to Simon's comment, trying to get back to the charge, I think what we are talking about is when we say study the issues related to the adoption of uniform data standards for PMRI, and the electronic exchange of information, this is an issue regarding electronic exchange of that information.
If you are talking about communication, it's an issue of electronic exchange when we don't have enough people plugged in. I think it's definitely within the bounds of the charge. So that's how I would sort of characterize it.
DR. COHN: Now Kepa raised his hand and wanted to talk. I would just comment, Richard, in terms of the privacy and confidentiality, which I think are very legitimate issues. There is actually a hearing on the Subcommittee on Privacy and Confidentiality intending to look at the Internet companies coming up I believe in February. So not in any way to answer that, just to comment.
Kepa?
DR. ZUBELDIA: Commenting back on Rick Peters' presentation yesterday and this capitalization. I don't think it's a problem if the industry, because of the huge amounts of venture capital, wants to come up with an industry-lead standard. If a company wants to bubble up and be the dominant player, it would probably be good for the industry.
The problem I think is all these inflated companies trying to be at the top of the heap. Instead of having one big heap with one leader, we are going to end up with lots of little hills, little leaders, and we'll be worse off. I think that's what we need to realize. It's a threat, and the threat is not that they are not going to follow a standard. It's that they are going to try to create multiple standards.
MR. BLAIR: I also was impressed with many of the new perspectives and ideas that Rick Peters introduced. When he was pointing out the fact that the Web-driven health care offerings which include information on the Net, and also include individuals that are beginning to develop their longitudinal health records on the Web, is coming forth. And that many of them have been blessed with tremendous amounts of investment by Wall Street.
I think all that's true, however, I think when you begin to relate it back to what our mission and what our role is, and how do we wind up facilitating standards for patient medical record information, it doesn't change the fact that in an acute care situation, in an intensive care unit the kinds of needs that we have identified during the six to eight months are still relevant.
Those are not changed by the fact that somebody might be setting up their longitudinal health record, nor the way we capture ambulatory information. I think that the thing that does change with this information is that the sense of urgency increases, the need for communications increases, and now the communications will have to be over the Internet and over the Web maybe more quickly than we had anticipated. We just figured we were looking at these systems primarily driven by the needs of providers.
MR. MAYES: I just want to make a quick comment to tie this discussion we are having right now as well to the comments that Peter Waegemann mad. I think it's very important that we realize that while the delivery of individual health care is still local of course, that much of the industry is becoming internationalized. We really do need to take seriously what is going on in the standards world internationally, for both the economic reasons that Peter suggested, and for the very fundamental reason that once you get on the Internet, it doesn't matter where you are.
Dr. Bebee's(?) company, anybody, it's already happened. We haven't explored it, but it is already happening in transcription. Tremendous amounts of data are being actually sent, stored, utilized by US companies in India and other places around the world. So there is that whole other aspect that does link over to privacy, but it also is going to impact because more and more we see outsourcing, which is another one of the issues that came.
Outsourcing doesn't simply mean sending it across town anymore. Outsourcing increasingly in health care means sending it across the world. And so obviously the international standards, just from a standards perspective are going to play into this. And then there is the privacy and the whole issue of regulating that opens up very interest issues.
DR. YASNOFF: I wanted to agree with Jeff's point, but with a slightly different perspective. I think one of my conclusions from Rick Peters is that because of the -- we have heard from many testifiers that the lack of standardization, and the need for mapping and translation of codes and so on is a substantial cost that is imposed on everyone who is working in the field.
Given the financial situation in both health plans and in the HIS vendors, it seems to me that their degraded financial situation means that it is even more urgent and more important to remove these unnecessary costs by fostering improved standardization.
DR. FITZMAURICE: I want to add and support what Bob said about that we need to be aware and participate in what's going on with the international standards, not only information that flows internationally. We are starting to see products flow internationally; computer programming. We are seeing pharmaceuticals flow internationally as people start gravitating toward lower prices. It's being driven by economics.
These are markets in which each country will want to play in, and understand what's going on. If we don't pave the way with good international standards, somebody else will do it for us. And it may not be compatible with the way we practice medicine in the United States.
MR. BLAIR: Michael, I would like us to capture an additional issue. The additional issue, and I don't have an answer for it yet, but the issue is right now with respect to drug knowledge bases. There is a lack of coordination in that particular area. And I think we may have to still do some exploration to understand that a little bit better in order to see what kind of wise recommendations we can make to help that situation.
DR. COHN: Bob, which topic are you discussing?
MR. MAYES: Actually, just a very quick expansion of what Jeff just said. Then I had a completely other point that I wanted to make.
DR. COHN: Make the comment on Jeff.
DR. FITZMAURICE: Let me make sure I understand what Jeff said.
DR. COHN: What I'm saying is we've got three or four different topics going right now, so we need to begin to close off some and open up others.
MR. BLAIR: Let me repeat, and I've carefully chosen words here. We have an issue. And the issue is that there is a need for coordination -- better coordination and interoperability for terminology among the drug knowledge base systems.
MR. MAYES: All I would like to say, Jeff, is that what I heard is that's exactly the same issue across the all the terminologies. It's a little more concise within the drug knowledge companies, because there are only three of them. But these are the same issues around other vocabularies that we have had discussions about, whether it's the CPT or SNOMED or whatever.
MR. BLAIR: Well, could I make the distinction though. When Judy Ozbolt, testified the private sector is already beginning to go forward to reconcile FS, and we have other things that are in the private sector that are going to address the need for coordination. I agree with you that the coordination is across the board. I just think that the solution in the drug knowledge base area may have to be looked at independently.
MR. MAYES: Well, until I see actual positive outcomes of these other coordinated efforts.
DR. COHN: Dr. McDonald, what topic are you discussing, do you want to comment on?
DR. MC DONALD: I wanted to comment on other comments.
DR. COHN: I'm trying to get the comments out, and then at least shut down two of the different.
DR. MC DONALD: Well, on international standards. But I basically want to say that I think everything's true that it's this international world. But I think that there is an inference made, and maybe because of the way it started. Peter Waegemann was talking about ISO. I think we should be very careful about assuming ISO and international synonymous for a couple of reasons.
One of them is if we are talking about US interests, the US standards are the most dominant in the world, and the ASTM is international, HL7 is international, DICOM is international. The second part is the lesson of ISO OSI versus Internet is a very instructive one. In our kind of crazy cowboy way of just trying building on it and trying to build on it isn't all bad. This having a huge consensus and then this is law.
DR. COHN: Did you want to comment on any of the other issues that are outstanding?
DR. MC DONALD: Later.
DR. ZUBELDIA: I would like to make an observation that may be off the mark, but just in case. On the administrative side, everybody maintains their administrative data in different ways. And nobody is trying to standardize how you maintain administrative information. We have standards for data communications, and the 837 is a standard for data communications --
MR. MAYES: It's content as well, Kepa. Remember, the HIPAA standards are content as well.
DR. ZUBELDIA: But wait. The X12 standard is a standard for data communication that can be used any which way you want. During the HIPAA process we have tied down the standard to make it also into standard data content that is tied to a standard for data communication, but is such that it cannot be implemented as a database system for administration.
Therefore, it's not a threat to the practice management vendors, because they cannot implement the 837. They have to map to the 837. They have to map to these transactions. None of them are a threat.
On the medical records area, I think we are seeing something different. We see the vendors like 3M right here now, they have developed a proprietary system, proprietary coding, proprietary databases. And they are understandably afraid of losing that proprietary nature, because they lose their competitive advantage.
On the other hand, the communication standards such as HL7 are not tied to the data content itself. If a communications standard was to be tied to a data content in such a way that we have the standard data content mandated by the communications standard, just like we do for the 837, but it cannot be implemented as the medical record system, because you just can't do it without HL7, maybe it would not be a threat to the vendors.
And maybe the vendors would cooperate in tying down that communication standard with data needs much better than what we are trying to see today, that the vendors are afraid of losing their competitive edge. I don't know if it's feasible or not.
DR. MC DONALD: I think there are a couple of threads in there that I would like to separate out. One, I think the distinction of communication versus building the system as a standard is very important, and I think it's all successful standards that make communication interface standards. So I think we want to be careful. We don't tell people how to make a phone right now, but by jolly you can take a phone and stick it in any jack. So I think we should hold onto that thought.
The idea that the vendors don't want this is wrong, I mean absolutely wrong. The medical record system vendors at the moment are most desperately wanting to have standardized vocabulary and standardized messages. Furthermore, the weakness of HL7 is that if you don't standardize the codes, it's still a help. SMS -- I read their testimony -- said most of the work is doing all this mapping work.
So all of the vendors who are offering these systems would rather not have to spend so much enormous labor and take a three timeframe, or a year or six months because this is a disincentive to everybody. But I do think the idea of saying we are going to make a standardized medical record as a functioning system is pushing the edge. As long as we can send all the data back and forth, you get the same thing.
DR. COHN: And I think that's why the legislation talks about the electronic exchange.
DR. LAU: May I comment, please, since 3M was mentioned? I think that's definitely right. As a vendor, I would be extremely happy if there are standards that I just use. Certainly the product is proprietary, but the vocabularies and terminologies are not proprietary at all. In fact, as I like to say, we are really quite neutral. If the source vocabularies are public domain, then good, nobody pays. The source vocabularies are not public domain, well, guess who pays? It's not the vendor. It's the end user.
So it really isn't proprietary, and we certainly would support having standards, because it makes our job easier. Then I can concentrate on supporting the customer's need by working on the interface part, and I don't have to worry about all the soft part, whereas now I have to do both.
DR. COHN: Just to clarify, there isn't anything about standards that requires that they be free.
DR. MC DONALD: Well, HIPAA legislation says something about that.
DR. COHN: Anyway, just as clarification. Helene Guilfoy, Dr. Ferrans, and then I'm going to try to put things together for a moment or two, and then we'll continue on.
MS. GUILFOY: Mike and Lee and I had sort of a side bar at the break. We were discussing the difference between the format of the medical record, or the patient medical record information, the record layout, which I think the vendor needs to keep proprietary. It's their bread and butter as to how they have that record laid out, and how they utilize it so that can use it within the other structures and the other programs within their systems.
But for my purposes and for my sake, what I would like to see is that the information, the content as Bob is saying, be standardized. When I was looking around probably six or seven years ago to show to people what needs to be a part of a medical record, what needed to be part of an electronic health record, what was the information that we needed to capture, the only thing I could find at that point was 13.84, which was why I got involved at that point with ASTM.
If we could look at what that information is that we need to capture, then we could turn that information over to the vendors and say, we don't care how you store it, but what we need to be able to do as health care providers, the ultimate thing that we need to be able to do is we need to be able to use that information. If you don't capture it, and if we don't tell you what it is that you need to capture, I'm not saying that you need to capture it in six byte fields that need to be alpha-numeric and all of that kind of stuff.
I'm just saying we need to know marital status. We need to know the gender of the patient. I'm being very simplistic here, but there are times -- I know there has been discussion of ethnicity. There is no vendor that I know of right now that captures a separate field for ethnicity. Everybody captures race, but they don't capture ethnicity.
If it is mandated that ethnicity be a part of the information, then they're going to either have to add it to their systems, which is a major overhaul to the systems. Or I, as a user, will have to request that they capture it for me, if I want to be able to use it. At which point, whenever I add another enhancement to the system or a new release, then I've got to go back and pay the vendor to add that field back in again to their releases.
So if we had something that just said this what we need guys. You decide how you are going to store it, and how you are going to process it, but these are the elements that we need.
DR. FERRANS: Just to get back to the vocabulary issues, assuming we do standardize, and again, when organization like the one that I have an academic affiliation with look to buy these systems, and they say why does this cost X, and they say, well, so much is software. Okay, that's fine. Okay, so much is integration, and so much is the licensing fees.
Again, if those licensing fees are significantly reduce, I think again you are going to see that's the other component of accelerating the more widespread adoption of end users using this system, and people capturing the amount of that proper mix of coded information that is necessary.
DR. COHN: Dr. McDonald, I see you want to talk, but I actually have a question for you, just a question of clarification. And that actually has to do with the reference information model that is being developed by HL7. My understanding is that that actually does specify the content, as well as the overall whatever. Is that correct?
DR. MC DONALD: Sort of. These discussions are really has to do without kind of anchoring down some of these meanings. When people talk about gee, if there was just a data model out, I'll be happy. There are billion. Everyone has got a data model. It's not that -- it's which one you want to pick. None of them appeal to everyone.
Unless you study them for a while, you don't appreciate what they can do if they are sophisticated. And there are different levels of abstraction, whether the model has a field for potassium or has a field for the lab test ID. And we have tremendous confusion about all of that. But more or less, yes, I would say that what you said is true. But you could argue about it.
What I really wanted to get back to is just a clarification of distinctions. What I kind of heard you saying is yet another dimension of it. We have issues as to making standards that are enabling. So there is a standard for CD disk ROM. I can put any kind of music on that thing I want. It can be ugly, sound terrible, it doesn't matter. It will take it. I can put on just a little strip of it, or I can fill the whole disk up with it.
When we talk about ethnicity race, are particularly interesting ones. We talk about those. Those are prescriptive standards. That's something I wish the government would do, not standards organizations, or someone else would do. Because there are fights and battles with good reason.
And then you said everybody has race. Well, everyone has a field for race, but the most we see in our city when we looked at five hospitals is 20 percent of those fields get filled in, because people are embarrassed and all kinds of other questions. Race has just got five options, and ethnicity has got 200. So I can tell you folks, that there is going to be challenge in the line in our hospital when we have to have that extra question and get that resolved, and still the same number of patients with the same number of clerks.
That is, I would at least make those distinctions. There will be prescriptions done. And we're seeing where you have to have certain minimum stuff. It came out very nicely in some of the discussions with 837. We've got to have this. You can't do the job we are proposing to do without this thing. And both sides agree. It's nice when it happens that way. When one side says you must, we always have trouble in America.
DR. COHN: I just want to sort of stop for just a second and make sure that -- we're sort of talking about many different things at once. Margaret A. has been doing a very good job I think at capturing some of our thoughts. I just want to go back a couple, down to number 4, since we're up to number 13 now, and just make sure that we are capturing I think the gist, without necessarily agreeing that we all agree to these comments, just for second, just to make sure that we have captured everything appropriately. And then we'll go back to the question of what else did we hear, and what are our learnings.
Now what we started off talking about, and sort of began to move from there without a chance to close off the discussion, there is obviously the recognition that Web-enabled Internet environments are an important factor that we need to be aware of as we move forward. Yikes. Margaret, would you please do me a favor and nod.
Can we go back to four now? I think we just observed that that was going to be an important I guess piece that we needed to be aware. We have obviously heard some testimony on that. But I think as we move forward, we need to be keenly aware. And certainly whatever recommendations we make, need to informed by those comments about the importance of the Web.
DR. FERRANS: And that there are privacy issues raised.
MR. BLAIR: Would it be all right if, since are taking a look at what Margaret has captured, maybe Margaret could read them off.
DR. MC DONALD: I think we should capture some more, because that's a lot of reading.
DR. COHN: We're going to continue on. I just wanted to stop for a second, because some of these were just sort of said. There were being argued and then we moved on without any sort of --
DR. MC DONALD: But these are not just simple bullets. We're going to spend a lot of time wordsmithing them I'm afraid.
MR. MAYES: I sort of agree with Clem. There are a couple of other issues we should at least get out there.
DR. COHN: Okay, rather than taking a second just to discuss them, do you want to add some additional pieces?
MR. MAYES: These are complex issues, and I think that we could wind up just with these -- probably with just the first one or two, and spend the rest of the entire morning discussing them. There are at least one or two others that I think came out pretty loud and clear, not just yesterday, but previously that we really need to address.
DR. COHN: We're at number 13. Give it a shot then.
MR. MAYES: We have heard over and over and over again about incentivization, incentivizing, and particularly from the government perspective. What is interesting is the wide variety of incentives that have been brought up, ranging from direct financial incentives, vis-a-vis legislative tax breaks or whatever, through a whole range of both direct and indirect incentives.
I think that it would be very useful, whether it's this committee, or whether it is a recommendation to the secretary -- that actually might be as well -- to recognize that it would probably be very fruitful to have an analysis of a whole variety of incentives that in fact are potentially available through the federal sector.
They really range quite widely, some of which they range from legislation, which is not always the easiest thing to get, to relatively simple changes that could be directed within a program basically by the secretary or by other people responsible to the program. I think that everybody sort of sees incentivization from their particular point of view, but I think it would be fruitful.
DR. COHN: I have been reminded by what you have just said that we had identified at some point that we wanted to have a sort of mini briefing on the nature of the incentives that the government might be able to provide. Am I mistaken about that Mike? Do you remember that? We identified that not today, but it would probably be something that we might want to have somebody come in and talk for a very short time, and provide some background material.
MR. MAYES: But I think that a very short briefing is not going to do it. I think that if you really want the federal government to incentivize, that it is really important to be able to specially catalogue a whole range of incentives. It's not something you can say, well, here are the five ways to do it, because just like everybody else, the government is in business. Each agency has a business. Their monies are obligated for specific purposes.
So I'm just throwing it out that a recommendation might be to actually thoroughly understand from the federal perspective, what are the ways they can incentivize. Some of the out of the secretary. The secretary can't pass legislation. So tax breaks, which was one we heard yesterday, is beyond the power of the secretary of Health and Human Services to implement.
Down to other ones that even somebody at my level within an organization could actually implement just by the authority I have in running certain programs. So there is a whole range, and I think it would be fruitful for people to understand that.
DR. MC DONALD: I would like to follow on that. I had the advantage of reading through all the testimony yesterday so I see -- maybe the highlights jumped out more. I agree 100 percent. I would like to highlight one of the ones I noticed, and it's an easy one is for government agencies to adopt the standards for whatever area they are in.
That has a tremendous power in terms of galvanizing and getting people to see leadership and all the rest. So I put that on the top of the list adopting A or B or C, whichever pieces. And then of course with the HIPAA legislation you have taken leadership. But there are other opportunities which wouldn't be quite as radical.
I think it's going to be harder to push and force standards in this more broad medical area than it was in the administrative area, but there are tremendous opportunities by just the government saying we're going to use this and we're going to use that. Or you must report to us this way.
MR. MAYES: Right, that's what I'm saying. There's a whole range of financial, or regulatory relief or regulatory burden.
DR. MC DONALD: The other one I would like to argue against is I don't think we should be sending people to HL7 or ASTM or any meeting. It just isn't the American way, to pick one person to get the scholarship sort of. The only way you might do that is maybe through an educational thing. There are traditions for that. Students get sent to things, and that's the only thing I know of that we have a tradition on.
The other thing is I think it's going to be hard to figure out the funding issue, if you want to fund directly, because again, if you give it to everyone, then we don't have any way to sort out which survives. We would still have the VHS and beta if we did that, and you don't want that. We really do want to get it down to one in a given domain.
DR. COHN: I'm hearing two things. One is the recommendation that we potentially look further into the whole variety of incentive mechanisms, and then I'm hearing some very practical specific recommendations. But I think that certainly we should look at the --
MR. MAYES: I think that one leads to the other. I think it's important to lay it out as how things actually work, and illustrate them by specific examples. But there are pluses and minuses to doing any number of these.
DR. MC DONALD: Margaret, I did make a specific point that you didn't get. That is, the government adoption for reporting in various ways has tremendous power without being very offense, because they are going to pick something for reporting.
DR. FERRANS: I would support what Bob said with regards to incentives. I guess my question is how do we do this? Should we make a list of potential incentives, and then have someone do a briefing, or have someone do an analysis? Is there time in the work plan for someone outside of this group to do an analysis of incentives that were recommended from testimony?
I would presume if we by August need to make a report with recommendations and legislative proposals, some of those might revolve around incentives. Or we may recommend to study the impact of these incentives.
MR. BLAIR: A couple of different things here, if I could tie it together. Yesterday we kind of reviewed the detailed schedule. Margaret and Simon and I talked about this a little bit more. There are a lot of different ways that we could do this. I'm not saying this is all locked in. We could change it if we want to.
But the thought was that whenever we begin to discuss recommendations, the discussion seems to come apart because it isn't tied neatly back to the exact circumstance. We have a broad diversity of testifiers testifying from different perspectives, and different segments of the health care industry. And the thought was that if we concentrate on the observations and the issues first, and try to tightly identify them to where they are coming from, from there we could wind up saying what recommendations could address those issues more specifically, and we won't be floundering around as much on the recommendations.
Anyway, that was a process that we thought would be helpful. Do we want to revisit that process? Is that not a good way to process?
DR. COHN: Actually, Jeff, I think it's a good process, and I would second it. I think we were still trying to get all of the learnings from the last few days up on the boards for part of that analysis. Maybe it's time for us to transition.
MR. BLAIR: Let me get one other piece in there, because I did think that when Blackford Middleton gave us the presentation, he had some I thought, very rational recommendations for how we might present this information in the report, where he started off with where are the compelling or driving forces. And I think this tied back to Simon's comments yesterday in some of our discussions yesterday afternoon.
But I thought we wanted to maybe capture that on the observations of what did we learn, to make sure we look back at Blackford Middleton's recommendations as to a good way to convey our thoughts in the report.
Then the last thought that I had was, Clem, you had said that you were saving some of your thoughts until later, and I didn't want to lose them. So have you had a chance to express them all, or is this later?
DR. MC DONALD: Well, if you can tolerate. I think it came out yesterday as I heard first thing in the morning. There really are two opposing views about vocabulary standards. There are two opposing realities that we have to kind of be conscious of. I think the system vendors by and large prefer that the vocabulary standards were free. They wouldn't mind if they were modestly priced and predictably priced. That is, there was kind of a guarantee.
On the other side, there has been an evolution of some of the vocabulary vendors. They have merged, and they have become fewer, and they have a business plan to capitalize on their purchase and expensive investments they made, which also makes sense. So that's one sort of tension that exists out there.
The other tension that's sort of larger and more relates to it more philosophically is that there is no problem in the US or anywhere with anybody selling anything at any price. That works. It's perfect. It's great, because if it gets too pricey, they buy it from someone else, or someone else comes in the market and makes the same thing.
Where we have a problem or a conundrum or where this whole system breaks is what we in this committee and others in the industry would like is to have only one. So we're saying we want to have a monopoly. Then you don't have that fail safe mechanism of the wild pricing.
So the risk is to those of us, I feel, who have been in love with medical informatics for a long time, is that we will end up with declaring someone to be the sole vendor, without any control on the pricing, and we'll have a disaster. We'll either have a real bad or crummy product.
So there is the real challenge. We can come down to specifics, but I won't in this conversation. But that's the challenge. So if we are going to mandate it or force it for some totally non-market purposes, we have to structure it so it is minimal or no cost I think. And there are a number of options for doing that. It doesn't mean it is minimal or no price.
Although the AMA has been lambasted for its charging for CPT for all these years, I just learned yesterday that pricing to an individual organization is typically pretty modest, because they don't do seed costs for the whole organization; seed costs for people doing the coding at discharge, which tends to be limited.
If I am a vendor building a system, and I kind of buy into some commercial vocabulary system, that's fine. I'm a grown up and I can make those decisions. But if I make a $10 million investment in software, and now I find that the price of the vocabulary went up 100 fold next year, and I have no choice -- some bad things could come out of this, and they are understandably bad.
So we have a challenge, because there aren't good models for how you have this competitive system and prepricing, have a unified, everybody has to use it system.
DR. COHN: Clem, actually I agree with the comments that you have made, though I am reminded when I was growing up there were regulated monopolies, at least where I lived, that used to deliver electricity and gas, and I think still deliver water and things like this. So potentially there are some models.
DR. MC DONALD: But they are not good ones. And I'll say they are not good ones, because they were guaranteed a profit, not efficiency. So they had no incentive to be efficient because of the guarantee of that 50 percent each year.
DR. COHN: Good point.
DR. MC DONALD: You can have some really fancy meetings, which I love to go to, as part of the business of doing the vocabulary. I think of some nice places that are $1,000 a day that I've never been to, but that would be supported by this function and that model. So I guess I shouldn't be arguing against it.
MR. BLAIR: I have a question. Clem, this is primarily addressed to you, but it's to anybody else here that has a thought on this. Forgive me. It's reflecting my engineering background, where I tend to do things in a certain organized manner, which works and doesn't work sometimes.
I sort of hear implicit in what you are saying that there a number of different terminologies that meet market needs. And that it is almost as if you are already at the stage where you sort of know what they are, and sort of feel like the rest of us know what they are. You are already down at the level of the pricing part. I'm not entirely that that's clear for our report or our recommendations.
So I have a suggestion. You tell me whether you think this makes sense, or whether it doesn't. My thought is that we need to focus on -- especially if we are going to try to say that we would recommend adoption of standards, that we need to focus on what are the criteria for those standards that we would recommend be adopted, which would be based on function and the ability to meet market needs.
Then if we wind up seeing that several of them turn out to be ones where the user fees are an issue and a problem, that that then be addressed as the second step. But I don't think we should step the first step. Do you feel like that's correct or not?
DR. MC DONALD: You made a statement that everywhere that is finished and we just have a make some choices. I don't think that's correct. But on the other side of it is if we make this a two step decision, I mean it's staring us in the face. It's discussed at all kinds of meetings. It's a hot issue. I don't think we should hide from it. We can do these things in parallel.
Anyway, what are the possible models that would satisfy the interests and needs? Now one of the ones is that you make the codes free. One model that has worked for some companies is have their codes be free, and the connections and all that are not, or the additional data. ACRI does pretty well with that.
So I don't have an answer. I just think we shouldn't shirk from the fact that this is staring us in the face. There is a darn good vocabulary out there that I think we could get on the bandwagon really easy if one wasn't terrified of the future.
DR. COHN: Clem, thank you. I actually wanted to pull back a little bit, only because I wanted to make sure that you got your issues on the table. I think that everybody has a tremendous desire to solve the problem in the spot, any issue you bring up. I just want to observe that we're trying to make sure we get them there now.
Bob, I will let you go, and then we'll come back to Clem.
MR. MAYES: This actually is a generic comment on these issues. The requirement from the full committee is of course a report to the secretary and legislative recommendations to Congress. There are some choices here. One can be a more or less generic report where we outline the broad areas of concern, describe in some detail some options, almost like an options paper for a briefing, and just sort of say and we recommend option number one, but not get in much detail.
That really doesn't work for legislative proposals. Most of us sitting around the table have been dealing with a particular legislative proposal that became law, and even with what looked like a fair amount of specificity at the front end, we have now discovered through our three years of working on it that there is still quite a bit of interpretation that it leads to.
I think I would urge the committee to be bold. And by that I mean to focus. Go ahead and make the overarching introduction that we have identified six focus areas. And I don't really think there is time to get to the level of specificity that I think each focus area could deserve.
I would describe, perhaps do a overall picture saying these areas are important, and they need to be focused on. We have picked this one as the most important. Here is a very specific proposal that includes incentives. It includes particular standards, if that is appropriate within that proposal.
I would hate to see the committee have spent all this time to produce a report which is simply a report that just basically -- because we have had a lot of reports. We have had a number of organizations that have been created; some have continued, some haven't.
I really think that we should take one of these -- whether it is vocabulary. That is obviously a big one. We keep hearing that over and over. And drill it down, and say here is a proposal. Here is actually a legislative proposal. This is what we would like to see in law, that this or this would be required, and here is what it would be. The same kind of language.
If we are thinking that it has to come out looking, at least a first draft of what the HIPAA --
MR. BLAIR: Did you really mean law, or did you mean regulations?
MR. MAYES: Legislation is law. Now you could back away and say that we think that this perhaps doesn't have to be legislated, and it can be regulated, but regulation if you look -- and I know you have, Jeff -- if you look at what a final rule looks like, the more specific you can be, the better off you are going to be.
DR. FITZMAURICE: I think you want the blessing of Congress on something that affects the nation.
MR. MAYES: I just throw it out that we really at some point would be better off driving at least one point of specificity that had some impact.
DR. MC DONALD: Could you modify it, instead of saying it must become law, just say very specific recommendations that could be turned into law.
MR. MAYES: You could handle it a couple of different ways.
DR. MC DONALD: Let's not shirk from our duty.
DR. FERRANS: One of the things that Mike did yesterday was point out this method of starting out with issues and working down to recommendations and specific recommendations. Although that would not be the format of the final report or the letter to the secretary, that is an appropriate way I think to do the drill down that you are talking about, so that we don't miss the opportunity.
DR. COHN: Yes. I think I can assure you that at least the intent is that we'll drive down as specific as we can based on our ability to have consensus, agreement. That really is the limiting factor in all of this.
Dr. McDonald, did you have other concerns? I'm going back to you because you said you had a couple of issues. You brought up one.
DR. MC DONALD: I have some issue on how it got represented in big, bold type, but I can fix that later.
DR. COHN: Remember that right now we are talking in the context of what we have learned, and our thoughts over the last two days. We are going to begin to transition, if people have other comments, into the question of how we proceed on into December, the format, the issues. How we are going to start peeling this onion.
DR. FERRANS: I actually had more of a question to everyone else to sort of open the discussion. I think a lot of what we have been talking about in terms of what we have learned has been about terminologies. I haven't heard as much of message format standards. I would see if we could sort of turn to that and see if anyone had any thoughts on that particular one.
DR. COHN: Are you transitioning now into the how we're going to peel this onion?
DR. FERRANS: No, not so much as saying we're putting up the issues there. We're making sure that we capture them all. We're trying to make sure that we captured everything that we heard over the last couple of days. Most everything we have been talking about has been about terminologies, and not about message format standards. I just wanted to make sure that we sort of touch on that, and anyone who has any thoughts or input about that --
DR. COHN: Did you have a comment?
DR. FERRANS: Sort of a couple of things going, but I would rather someone else start, and that will trigger my thoughts.
DR. MC DONALD: There was something in the October 15 body of the report under message format standards and medical terminology or something that says issues derived from the message format convergence document, issues derived from the medical terminologies convergence document. I'm not sure I have those documents.
DR. COHN: Those actually are not documents. Those are informal overheads that we developed to try to synthesize the hearings from those days.
MR. BLAIR: Just incidently, they are really quite the same as what you had in June.
DR. MC DONALD: You have identified them. Thank you.
MR. MAYES: Just a comment on the message format. I have been hearing quite a bit on message format. That is the word 'Internet' because that brings in a more fundamental issue, which is are we still living in the world of messages? Broadly you can say we are, because messages are communication back and forth, but there are a lot of people who say the more focused or more historical definition of a message being sent as a monolithic unit back and forth, and being decomposed at the other end is perhaps not where we are going.
In the broader -- distributed computing and other things, that whole concept is becoming a little less clear than it might have been.
DR. MC DONALD: Could I just comment on that? This is about my 18th year in standards. Every three years there is a new messiah. It's what is killing us, because we don't ever finish the first one we started. Messages -- that's what Internet is. The IP sends a message. But it is a message format. Internet is not a message format.
We are really talking about all the specificity that is required to say what it is, and where the birth date is and those kind of things. So if we keep changing -- it takes a long time to move an industry. It took 50 years to get the whole interstate highway in for example. I think it took 35 years before half the televisions in the country had color TV from the time it was invented.
So if we don't keep our eyes on the fact that it takes a long -- and no one is still doing metric very well, even NASA. So if we are going to get people to standardize, we can't keep changing our mind about what we are trying to do every couple of years, but we can incorporate the newer things. I think there are layers that make it work well.
But I really think X12 is 10 years or 18 years. We shouldn't be trying to refine the reality, because we'll never get it done. I promise you we won't get it done, because at least if the past is any prediction.
MR. MAYES: When we talk about implementation of even the 837, we have to differentiate between batch, whether it's single or online.
DR. MC DONALD: Well, that's fine. Those are different attributes, but it's not either/or. And a message isn't necessarily a batch.
MR. MAYES: Even a batch of one.
MR. BLAIR: With respect to what we have learned, or what concerns or issues there might be with respect to message format standards, the view that I had was that HL7 was very successful in the marketplace, meeting most of the needs, maybe not quite as fast as everybody had wanted it to do, but it was pretty much addressing most of those needs, and it pretty much seemed to have the support of most of the vendors and users.
DR. MC DONALD: Providers as users.
MR. BLAIR: Thank you, you're correct. Clem, maybe you could help with this. As the idea of consumer access to health care information has come up more clearly, especially yesterday, and the idea that maybe we would be sending health care information over the Internet with TCP/IP protocols and HTML, I thought that that didn't really change very much the needs for the health care message format standards or HL7.
I remember just reading a few days ago that HL7's 2.3.1 employs HTML coding. It's been adjusted for that, and it looked to me like it was a pretty good laundry list of all the different messages it covered. So I thought that kind of was taking care of it, but I have heard from some individual, concern about whether HL7 message formats will be able to meet the needs in the Internet environment.
Clem, can you give us some guidance on that?
DR. MC DONALD: I can give you some historical realities. I heard 10 years ago ethernet would not meet the needs. You definitely couldn't do ethernet. It's almost always spoken by someone with a totally different idea. So we had 10 megabytes. Then lo and behold we got 100 megabytes at the Net, but there was no way ethernet could get beyond that. So it's going to be Sonet(?) and it's going to ATM, and lo and behold I was just reading about copper gigabit ethernet in a paper last night. In fact, it's being sold, but it isn't quite out there enough.
There certainly has been for a year or two now very successful fiber ethernet at a gigabit, and it's wiping the heck out of ATM, because it really is standardized across vendors, and it's cheaper by 75 percent.
The power of the Internet has been, and I don't know how they did it, the original guys, they used a little bit of a club in secret I think, because everybody had to use IP. You couldn't invent a new IP every two years. And you would say, well, we've got this new application, we've got to get rid of IP. It won't work. We'll make a new thing. No, they've got to use IP.
They are using SNMP in a mail protocol for managing ethernet routers and it goes on and on, because that's what they had to do. They had to figure out how to extend it. You maybe made a layer on top of it if you needed other features. So the long answer to your question is I think the content is the content is the content. And HL7 does a pretty good job with the clinical content.
There are issues as to how do you know who is asking for this patient's record when he says he's John Smith. It might be Mary Smith trying to find out if her husband has syphilis, which might be okay, or it might his employer faking his name and asking whether he's got sleep disorder or Parkinson's or who knows.
So we've got other layers of problems that are not going to be satisfied with the current functionality, which is not related to the message, but how do we be absolutely sure who the heck is probing this record if it's a shared record, that is if it's not a record they themselves stored, and they have their own private account number, and their own private password. So there are issues involved, and I don't think they have to do with the basic messages.
DR. ZUBELDIA: Jeff, let me try to address that. For the transport of the information -- I think this is what Bob was referring to -- for the transport of the information, HL7 is a great vehicle for a computer-to-computer transport, application-to-application. When you are going to interface with a consumer, with a person on the other end, HL7 is pretty much meaningless. You can't see what's inside that message.
So for the consumer that is most likely going to use a Web browser or some sort of planned application, HL7 is pretty much irrelevant. They want to see the information. They don't care whether in the back HL7 is being used or any other standard, XML, it doesn't matter.
DR. MC DONALD: It does matter, because you are going to retrend all the suppliers if you declare, oh, I'm going to start over again. I say we sent over HTML. The browsers all show pictures just fine. It's called jpeg, and there is a plug-in. It would be a high school student's exercise to write the plug-in.
DR. ZUBELDIA: But let me put it in the perspective that we do today for instance transactions. The standard for eligibility is 270, 271. We have implemented that with the HIPAA version. We do that by the millions a day. When it's time to interface to the consumer, to the provider that is going to use a Web browser, and there is a very small minority going that way, I would say you can count them with the fingers of one hand those that are using that, as opposed to integrating into the practice management system.
When we go to the consumer, we send the 270 to our Web server, or we get a 270 from the Web server and we send a 271 to the Web server. The Web server is going to translate it into a human presentation that has the same content as a 270/271 presented to the consumer in HTML. That is where the interface to the consumer is that important. So you view the Internet as a message standard. I don't think it is a message standard. It's a pipeline.
MR. BLAIR: It's a pipeline, and that was really the thrust of my question. Let me get back here. I think the thrust of my question is that the Internet is really not changing what we are looking at in terms of message format standards for patient medical record information. HL7 is going to continue to meet those needs. And it is going to be within the pipeline of TC/PIP, correct?
DR. MC DONALD: I think it's correct.
DR. FERRANS: Clem, the question that I had was, and to you and Jeff and everyone is given the fact that we have a message format standard that is widely adopted, but voluntary, and that it seems to be meeting the needs, what is it that we should do with regards to that? The issue is what is the appropriate action, if any in terms of recommendations?
One of the recommendations, and I think someone said it a little while ago was the government ought to adopt it for use in government agencies. There is something up here about the GCPR adopting it. What is the impact of that? What are some the remaining issues regarding HL7 as a message format standard, and what role if any should the government play in facilitating or improving that?
DR. COHN: So you brought up the issue?
DR. FERRANS: Yes.
DR. COHN: Any comments, not necessarily trying to answer that one.
DR. ZUBELDIA: I think kind of in addressing that, I think that the role is to officially bless it, and say HL7 is the recommended standard. If you talk to some of the European people, they will say that they want to go with EDIFACT.
MR. BLAIR: For patient medical record information?
DR. ZUBELDIA: Yes. You go to the EDIFACT meetings, and that's what they talk about. I think that if we say HL7 is the adopted standard in the US, I think that will be positive.
DR. COHN: Well, and we should also observe that if we are any way taking the lead from the other HIPAA standards, we didn't necessarily say that all of the X12 transactions were standards. We said that some of them were. So we did have an option. We can say yes, that's the group. We can say that certain parts of it are a standard or otherwise.
DR. FERRANS: I would also add that a message format standard, in my opinion, can be viewed as an EDI standard. And that like X12 there are rulemaking processes that have been established for EDI standards, and that's something that could be done.
DR. ZUBELDIA: Can I say something about X12? I think that X12 as a standard has been there for a long time. The amazing thing that HIPAA has brought to the X12 is the standard implementation guide, because the standard is not enough. The standard implementation guide will make it happen with the standard data content, the standard data requirements.
MR. BLAIR: That's a very good point. Make sure we are capturing that.
DR. MC DONALD: Again, there are two cuts on this. The currently mandated administrative transactions, not all of them, are really what could be described as a data set. You are saying not only how to send it, but what must be sent. That gets trickier, but there are certain domains in health care -- you don't get a serum potassium on every patient that comes in. We would like to be able to send it to certain people if you go it. Actually, there is no such thing as a serum potassium. So that's one set of issues.
The other side of it is that if you are going to send something, the vocabulary has got to be completely specified. That's what has happened with the implementation guide too. Now to say that we can completely specify all vocabularies in health care is going to be a little harder, so we have a little tougher challenge. But having good, standard vocabularies will make messages far more useful than they will be without them.
DR. FERRANS: I would also add the piece that people say when they talk about the downside of HL7 is that everyone has a different implementation. So even though there is a standard, there are still significant mapping issues. You get 60 percent or 80 percent, and there is the stuff that is sort of fudged. What you are talking about in terms of the other consequence of a standard would help improve that.
DR. MC DONALD: Well, there is again two pieces there. Half of what you described at variants is just complete ignoring -- they are not even close. They have never read the manual. Then there are few things mixed up, and then there are a whole lot of problems with vocabulary. HL7 doesn't require a specific vocabulary. And that creates problems to receivers.
SMS said it, most of their installed cost is mapping vocabularies, it's not dealing with an slight variance in the message. It's a tremendous problem. If you use vocabularies differently, actually you structure the messages differently in some cases. We have a vocabulary test that we're getting from one lab vendor that is called Other Test. That's the name of the test. Inside it they stuff two pages of report as one value, with 25 test results.
DR. FERRANS: What's the reference range on Other Test?
DR. MC DONALD: The reference ranges are stuffing the value too.
DR. COHN: What part of the problem is solved by the planned reference information model? My understanding is that much of this is beginning to be addressed.
DR. MC DONALD: Are we talking about reference vocabulary model or reference information model? I don't want to be irreverent, but I think the horse is out already, and the MCPP is, in terms of dominance of their market, the most successful standard. Everybody is happy with it. There is no model. I don't know if they are even worried about a model, but it works.
So that I don't think that that is necessarily a prerequisite for success. I think there are other examples. X12 didn't have a model and they are very successful. In some areas, shipping material management and transportation there is no model, and they are doing just fine. So I don't think it's prerequisite.
DR. ZUBELDIA: Probably the only model in X12 is the health care model. All the other guys are doing it without models.
DR. COHN: Just to finish this thought out --
DR. MC DONALD: But there is going to be one, and I think it will help organize discussion, talk, et cetera, et cetera. It's not a sine qua non.
DR. COHN: I think for me just to try to conceptualize what we have been talking about, I think what we are saying, and I think what Kepa commented on and others were saying yes to is the fact that for a standard to really be implemented nationally, it is helpful if there is a lot of specificity related to it.
I think Dr. McDonald you also commented that we the more we can talk about and specify its content --
DR. MC DONALD: Are you talking about prescriptive or when you send it, it's clear. So there are those two things we've got to keep clear. If you are going to have to send these 14 answers every time you send the stuff, that's one thing. And we will have political objections to some of that, because we won't be targeting the pragmatics correctly.
I'm saying if you're going to send a serum potassium, you identify it in it's normal ranges this way, that that's absolutely true. As you have a more and more abstract model and more abstract message where you say things, the field hasn't named the name of a test, the name of a blood pressure, it has a paired thing that says what the name is. If the code for that paired thing isn't specified, or is very variable, you've got a hard time communicating.
MR. BLAIR: Boy, Clem, I'm glad you're here. There are a lot of questions that we're asking. So now that you're here, I've got another one for you, because you were instrumental in providing a lot of input to the ASTM E13.84 document that Helene gave us testimony on.
You are also knowledgeable about HL7's reference information model. My understanding of that reference information model at HL7 is that it is essentially a tool which is being built by having use cases to try to help identify in as many different specific situations the data that would be required in a message so that it could facilitate more rapid generation of message format standards in the future, a la Version 3 and beyond.
So that it's different than ASTM E13.84, which was kind of like a conceptual collection of data elements. So my question to you is if this is generally correct, do we need both, or does one supplant the other? Or do they complement each other? Could you put it in perspective for us?
DR. MC DONALD: Well, this is America, so we always need many. I think they do different things. I think as I said before, the 13.84 is a little schizophrenia, and it hasn't delineated when it is trying to be specific and list out real, real fields, and when it is trying to be generic. But it is a useful document. It sort of summarizes about all the things you can enumerate that you might want to put in a medical record, and how you might group.
The data model you are talking about is completely technical. It should be automatable. The principal immediate value is it would insure that the message would be coherent. So if you make 25 messages, you will always specify the patient birthday the exact same way, because you are taking its complete definition out of the field in the model for that.
Now having said that, models are really bearishly difficult. IEEE started trying to build a health care back in 1987, and actually those same people merged into HL7 after a while, and they are still trying to build it. I think it's coming close to happiness. The newest incarnation is a more abstract version which I'm optimistic about, because you can actually see it on a page, so that you can absorb it. But the more abstract they become, the harder they are to convey. So there is some tension and arguments about it.
I guess that's enough said. But the short answer is -- well, that's the short answer.
DR. ZUBELDIA: I'm going to throw in a proposal. In December 1992, we were in one of the X12 meetings talking with Barbara Writing(?) of HCFA. What would it take for HCFA to implement the 837 for the first time, and to implement the 835 for the first time? She said, well, how would we do it? All we have is the standard. We can't implement the standard. Why don't you guys come up with an implementation guide.
So after the December meeting -- the December meeting was like Monday to Thursday -- six of us got together in an EDS apartment in Plano, Texas, with a lot of pizza and worked basically Thursday night until about five in the morning, and Friday from like ten until six or seven in the afternoon, and Saturday all day. And we had the first 837 implementation guide.
There were a couple of people from HCFA, but there were the chairs of the 837 work group and a couple of the experts. Basically it was a group of six people that came with the first 837 implementation guide for Medicare use. Now HCFA took it, and they said we are going to implement this. And they implemented the version 3030.
It actually never got implemented, because nobody can do it. But they officially said we're going to implement this. Then it evolved into version 3041. It had several releases. It was implemented. So when HIPAA came around, that was kind of the seed of the implementation guide.
But I think what made it happen was the fact that HCFA said we want the experts in the industry to develop an implementation guide for us, for HCFA to use for Medicaid Part B. Once the experts developed the implementation guide, HCFA went around to commercial industry(?) and said we want you guys to implement this. It has been developed by the experts in the industry for government use only.
After it has been implemented for government use, then the rest of the commercial industry said well, we'll use the government developed implementation guide as the model for the commercial part of the 837. And that has evolved into HIPAA.
I'm wondering if we could do something like that here as part of the incentives. Get the government to have the experts in the industry develop an HL7 implementation guide and a medical records terminology standard to be used by the government, with the intention that once the government has developed that implementation guide and terminology standard for the government, then the government can donate that implementation to the rest of the industry to implement.
Would that be a good incentive and a good approach?
MR. MAYES: Actually, my comment follows directly onto that. I was actually going to recommend that -- it actually happened, Kepa. CDC is working with HL7 to define an implementation, a message standard for immunization. And actually GCPR has pretty much decided they are going with HL7 as the basis for their whole variety of things. And they have explicitly from the beginning said we're doing this within our business context, however, we are doing it explicitly with the idea that it will be made publicly available totally.
And in fact, anybody who want to contract with us for our money has to sign that agreement that whatever comes out of it, they have to make publicly available. The point I was going to make earlier is that's exactly the kind of specificity and recommendation that I think is a perfect example.
For message standards, the general agreement, consensus seems to be in the clinical arena HL7 is a dominant player. It is not just dominant here. It is gaining increasing popularity internationally.
What would be most useful for the government -- and this gets to your saying the government should adopt, what does that really mean? What that really means is you do exactly as you just described, or what CDC is doing. So here is a way of saying we recommend that government projects that require public reporting of clinical information adopt HL7 as the message format, and that this be done by building implementation guides through the HL7 process.
Just basically flesh out exactly what you described. And we can point to some examples that are currently underway, that are proving successful. So basically you're not just saying try this on our recommendation. You're saying what we recommend you do is expand what is already happening and has been happening successfully, and here are some examples, CDC, GCPR, whatever.
I think that's exactly the kin d of thing that if you recommend it to the secretary, it has real meaning. Because I can get direction and sort of say, ah, I now need to go to HL7 to invest a not inconsequential amount of money it costs me to participate. I come there with a specific project, ESRD reporting or whatever, and I build my new reporting standard. It's not something I just make up with my contractor back at HCFA.
DR. ZUBELDIA: Then the government can say we will only medical record systems that are compliant with these implement guides that have been developed for the government.
DR. MC DONALD: That would be the most powerful thing you could ever do.
MR. MAYES: Or I will interface, and I will accept messages from anybody's systems that uses it. That's even more powerful than me buying a single system.
DR. YASNOFF: There is one other piece of that that I don't want to leave out. That is that there has to be a certification mechanism somewhere that says we have taken messages from this system, and we certify that these are really the HL7 messages that we are talking about. And they don't have a bunch of junk in them that so many of the HL7 implementations have.
DR. FERRANS: Let me second that, because I know that there are -- for example with the DICOM standard, which I am fairly familiar with, there is this notion of "DICOM" compliance. And different vendors may accept DICOM images, but they spit them out in their own proprietary format. People use retired data elements. People do a lot of funny implementations.
That has hampered the true interoperability world that people really wanted. People really wanted to have the choice to say I can get my variety of equipment from all the different equipment manufacturers, hook them up to a server and run them on the standard. DICOM has the messages and the image standards. And that's been a big problem, so certification is really key.
DR. COHN: Okay, I think we've caught that as a view now. We are at 12:10 p.m. right now. I'm fine to go to three or four this afternoon -- actually I'm not fine, but we could if we need to. The question is, I think we have completed this thought, and it's actually been a very useful discussion.
DR. YASNOFF: A powerful way to induce people to use standards is for the government to adopt them and use them itself.
DR. COHN: It's under 27.
MR. BLAIR: This kind of relates back to certain types of incentives that the government has available.
DR. ZUBELDIA: Let me point out a very subtle difference. If the government adopts a standard for other people to use, that will create some sort of backlash. If the government says we're adopting a standard for us to use, and if you want to interface with us you have to use that standard. You can use anything else you want, but this is the standard for the government. Then you are leading by example.
DR. COHN: I think that we can hone down on over the next couple of meetings, but I think we have the fundamental concept up there, which is the importance of implementation guides, the role that implementation guides would play in all of this, and the issue of enforcement. Actually, not so much enforcement. It's the question of identifying it indeed meets the standard.
DR. FERRANS: May I ask the question, when we get back to the money issue and the support for standards organizations, does this not in fact, as Bob suggested, bring government money to those organization by nature of the fact that they have to participate, and in essence, at least in the message format arena -- I'm not talking about terminologies, but at least in the message format arena, that that problem sort of takes care of itself, or is that overly simplistic?
DR. MC DONALD: The business of money is tricky. I'm of and from many standards organizations. I worked in CEN(?) where they pay you. Well, we thought that's the answer. If you just paid guys, we'd get all this work done. It didn't come out that way. There is something about this current, crazy way about where you have work nights and weekends, and you're not in it unless you really care about the stuff. If a company puts someone in there, they're doing it because they think it's worthwhile. There is a feedback loop in there that's somehow healthy.
On the other hand, modest, small amounts of money go a long way. The Internet is another example. There were small amounts of government money in that, that just had tremendous leverage. It was done in a very, very good way. And we have to be very clever. Like currently the VA and some of the agencies are members at the high levels. There are different levels of how much you have to pay. That's one helpful area.
There might be ways of paying for contracts for themselves. They would buy a big, massive contract, but with modest money. I think if you throw big money at this, I think you change the whole character of it.
MR. MAYES: I would push for a contract type of approach, a grant.
DR. COHN: And certainly I think we have talked about this one level of funding which has to do with funding of people to participate from the government to work on some of these things, which we've seen this whole thing before.
DR. MC DONALD: I want to make a distinction. I'm thinking HL7, ASTM, or DICOM, but when you are talking about the labor involved in say maintaining a SNOMED, a total vocabulary, if a funding mechanism was found to do that on a basis, and then could make the availability problem go away, that would be an interesting thing.
DR. FERRANS: I guess also from the certification end, about funding for certification, because if HL7 is going to have to survive, there is going to be cost, and they are going to have to pass that on. Or if there is going to be an independent body, as typically is done when you do certification, someone is going to have to pay for that.
DR. MC DONALD: Someone like NIST could do something like that.
DR. COHN: There are other models; ENAC.
DR. ZUBELDIA: ENAC has a HIPAA compliance verification system on the Internet Website where you can send an X12 transaction, any of the X12 transactions listed under HIPAA, and it tests it against the implementation guide and gives you a report.
MR. BLAIR: We have kind of covered a lot in terms of things we have learned about medical terminologies. And we have also covered things we have learned about message format standards. We've had some testimony with respect to data quality, and the pieces that I think we may want to capture from at least what I heard, and what I think I have learned here were the observations that data quality mechanisms are being suggested to be integrated into the message development format in HL7. Gary, when he testified, I think was looking for us to endorse or support that integration.
I think that the other piece was that Joint Commission and NCQA were also going to be providing incentives for improve data quality for them to be able to do performance measurements. And again, I think that they were looking to our committee to endorse that behavior and encourage it.
And are there any other observations with respect to data quality that we need to capture?
MR. MAYES: I have one. What I think would be extremely useful would be -- one of the real contributions that Gary and the others have been looking to make is to really give us a more formalized view of data quality. Everybody talks about data quality, but it's like one of these things that you bet you we're all talking about slightly different things on who is paying our paycheck, for what reasons.
Gary and his colleagues have certainly showed data quality is actually a fairly complex set of things that lead over to security very directly.
MR. BLAIR: Integrity, accountability.
MR. MAYES: There is just that whole area. That's very important. That is an area that can be formalized, just like messaging, just like vocabularies, just like security is a very important one. I know just speaking from my professional experience in what I do for HCFA, it is becoming an increasing issue, not only the quality of the specific is the data we're getting really representing what people think, but we're going to have to begin to address what is the chain that that data goes through, and what is the likelihood of changes.
Once you throw in this Internet, it ties into some of the concerns that were brought out about what good is what you are reading? Who is publishing this stuff? Where is it coming from? That kind of thing. So I'm not sure what the specific recommendation would be, but I think it would be very useful to acknowledge that it is complex, and that it has not been formalized perhaps as well as it ought to have been, and to encourage that.
MR. BLAIR: We also received testimony, and I don't know if this was captured in September or not, maybe this is duplicative, but we also received testimony from NCQA indicating the frustration that they are having doing meaningful performance measurements because of the lack of data quality. I think we certainly need to make sure that that is referenced in the report.
DR. COHN: I think I was also going to add in that we heard today from 3M from two issues related to data quality. Once again, it's perhaps a much less technical view, and I sometimes am fascinated by the many pieces of data quality, because it relates into terminology and the messaging standards and everything else.
But what they commented on was that they thought that there were two pieces to data quality, at least from one view. There are 100 pieces to data quality. They commented about the precision of the definition, the field and values.
Then there is of course getting the right value in there. You can be as precise as you want with hematocrit, but as she commented, you get 30 rather than 50 or vice versa. As far as I'm concerned as a health care professional, I consider that to be a data quality issue.
DR. ZUBELDIA: You can express it with two decimals.
DR. COHN: Now, do people have other comments? We're getting to the time when I know Kepa needs to leave. We're going to be wanting to wrap up. I do think it may make sense for us to take a couple of minutes and talk about the December meeting. Margaret, I was going to hand it over to you to talk for just a couple of minutes, to make sure that they types of things that we are thinking about producing and the approach we're going to take is going to be useful for everyone.
I think today has been extraordinarily helpful in terms of beginning to develop some ideas and recommendations. But I do think overall we're going to have to go back to peeling the onion. As I was commenting to Jeff earlier today, I think the value of our recommendations are going to be helping to lead people through the journey we have been on over the last year with the multiple hearings, the ingestion of information.
If the only thing we come up with is our final recommendations about the overall thought process, we will not be able to communicate meaningfully any of it to anyone. So Margaret, can you talk for perhaps a couple of minutes, and solicit input?
MS. AMATAYAKUL: I, based on the discussion yesterday, tried to capture and understand what would be the most helpful for you to have to look at in December. I think there are two things. There are some source documents. And we have talked about for instance going back and culling out every pearl in the testimony.
We have also talked about identifying every recommendation. And then this morning we talked about linking those individual recommendations to the person, organization, and perspective that they brought to that recommendation. And perhaps trying to look at those recommendations from the standpoint of duplication.
So those are some source data types of things that we can pull together. But that's probably going to be long lists of stuff that is going to be difficult for you to manage. So to try to pull that together into something that would be meaningful for you, it sounded to me yesterday like you wanted to insure that you had all the issues, that you understood for each of the issues, a goal that might be associated with that, or maybe several issues and one goal, or vice versa.
And that you would ultimately not necessarily decide in December, some of these might produce fairly clear recommendations, and others you would have to wait. But the ultimate goal would be to get a recommendation. So I saw the structure as sort of trying to identify the key issues, goals associated with them, and then recommendations either that were fairly clear, or that you would define.
Does that seem to help? What I did here was put an example together from something that we talked about yesterday.
DR. MC DONALD: Just a clarification to Mr. Chairman. Are we planning to, in our report, reference directions and issues to particular testifiers?
MR. BLAIR: What we were planning on doing we were discussing.
DR. MC DONALD: She is just talking about a preliminary document?
MR. BLAIR: Right.
DR. MC DONALD: Weave those connections in?
MR. BLAIR: Exactly. This would help us because in the process of trying to understand issues that appear to contradictory, if we can have these tags to them to understand the individual, the source, and maybe the perspective they are coming from, we could understand that the perspectives are different and we could see some clustering. So it's to help us in the work flow.
DR. FERRANS: It's a good engineering approach.
DR. COHN: I think this is a good process. As I look at your example -- I'm not interested in the substance of it, because it's only an example, but I think we need to be careful really being very precise about what the issue is. And when you start saying something is because of, and it becomes part of the issue, I think somehow that the issue and the because of is sometimes a slightly separate piece. We need to sort of glean the separation at some point.
DR. YASNOFF: If we are going to collect lists of say suggested recommendations from the testimony, if possible, I think it would be helpful to us if those could be organized in some way by topic or by type of recommendation.
DR. COHN: By issue.
DR. YASNOFF: But something clustered so that similar recommendation appear together, so that we can look at the different variants and see what consensus or disagreements there are.
DR. COHN: Bill, just to respond, I think what we are thinking about doing is trying to cluster things by issue under the broad focus areas as well as possible. I don't think we would want to start sorting things by recommendation, only because recommendation and more federal support -- there might be a long list of things that fall underneath that.
DR. FERRANS: Can we actually separate out, list the issue and then define it, and put contributing factors or some other sort of area, or the root causes? I'm sure we can wordsmith what the category so that we end up with four, the issue, the causes, the goal, and the recommendation.
MR. BLAIR: That's what we intended to do.
DR. COHN: Other thoughts? The whole point of this is to make sure that we do -- what we start coming up with is useful for everybody in terms of sort of a next step, which is this analysis and beginning to come together with our decisions and recommendations.
MR. BLAIR: One observation I may add, because this is asking for your involvement rather heavily here. According to the schedule that we reviewed yesterday Margaret will be pulling a lot of this stuff together, and attempting to distribute it by November 2 so that we could review it on either the 15th or the 17th.
So we are really looking to you to spend the time to go through the material that she distributes to you, because we will probably only have about two hours in that conference call. Any corrections, additions, enhancements we need to get in place. Now understand that conference will be the November 15th or 17th. It is going to be an attempt for us to narrow and get some consensus on what the major issues are.
That will be our foundation upon which to try to get ready for the December 9th meeting where we begin to wind up relating the recommendations to address those issues. That won't be the last time we do it. It will be first step December 9th. Then we're going to go through hopefully two more iterations before we begin to get this to the full committee. So that is the schedule, unless we decide to change it.
DR. MC DONALD: Regarding the notes up there, will we get a chance to edit those?
MS. AMATAYAKUL: Can I send them to you for editing? That would be great.
MR. BLAIR: Maybe Margaret has some more to share with us?
DR. COHN: Margaret, do you have any other comments?
MS. AMATAYAKUL: I just wanted to make sure that I have captured exactly what Jeff just said. That by November 2nd we will have the source documents, the issues, the list of recommendations --
MR. BLAIR: Not the recommendations. You probably have longer to get the list of recommendations out. We really want to have those recommendations in place to review by December 9th. But at least have the ability to review the issues with whatever supporting material we need to review the issues on November 2nd, so that we could agree on that at the conference call on the 15th or 17th of November.
DR. FITZMAURICE: Jeff mentioned December 9th, but as I remember we have the 9th and the 10th blocked out. That is a two day meeting, right?
MR. BLAIR: Pardon my parochial view. I was only focusing on the CPR work group. You indicated we might also have some time on the 10th as well.
DR. COHN: Yes. I think what's going to happen is that we are going to be needing a couple of hours to deal with letters responding to any NPRMs that may be coming out between now and December 9th, and other miscellaneous subcommittee business. My expectation is that that will not take the entire time on Friday. So I'm sure these discussions will move over into Friday also.
Now I have one other issue. Is it okay before I move on to this other question, going back to an earlier discussion having to do with the overall piece of incentives? We left out one sort of as a dangling participle in terms of we had discussed that we could just leave things as high level. There ought to be incentives. We can delve into understanding better possible incentives.
I think my hope was that we actually understand a little bit more about sort of the possible and the sort of variety of federal incentives that might be employed. I was actually wondering rather than necessarily hearing testimony on that, if there were something written that we might be able to receive, that we could review, that might provide us some education about that, and background. I'm actually looking to Dr. Fitzmaurice.
DR. MC DONALD: Bob made the suggestion. I didn't know whether you had a source that you could --
MR. MAYES: Yes, there is not a little handbook put out by GPO that talks about government incentives. I think actually some of it came out in the specific discussion for instance just on message standards. There is the incentive. The incentive is that you get a specific federal program to adopt the standard, and then by saying that, this is what you are actually meaning. Meaning there is going to be an implementation guide. That's one form of incentive.
DR. FITZMAURICE: Are you talking about something general, what are the tools available to the government? What kinds of things can the government do to incentivize?
DR. MC DONALD: Yes. And I thought it was also going to turn around and say I know there was one expert.
DR. FITZMAURICE: We could do two things. I could say here's what the government does. The government calls committees, the government raises or lowers taxes, the government subsidizes, so that you get a sense of what kind of tooly things can be recommended in the report. We can recommend this or we can recommend that. What are the things that government does, and maybe what are the things that government doesn't do.
DR. MC DONALD: I could get something together.
DR. FERRANS: Bob, one of the things I would love to hear from you, because I heard some recommendations earlier, people were talking about if there was reimbursement for people submitting to the government, structured, coded data that was more clinically specific, and the government could use that for having much better data quality to perform, in a different sense of the data quality work, but for its functions of assuring health care quality. Those would be reimbursed different, and things like that.
I'm not suggesting that we discuss this issue now, but it's actually HCFA issue. That is, the most powerful incentive on the other end that government typically uses, namely reimbursement for services by HCFA. So I would look to you to say what is --
MR. MAYES: For reimbursement it can be both regulatory or legislative. There is another way, which is regulatory relief. If you do certain things in a certain way, you don't have to comply with all this. So there is a whole variety.
DR. COHN: It's 12:35 p.m., and I guess the question is, is there anything else that we need to discuss at this point? I personally want to thank everyone, because I think it's been an extraordinarily productive morning. It's been very useful as we move forward.
Jeff, do you have some comments?
MR. BLAIR: No, just to echo Simon's thoughts, and thank everybody. I think it's been a very productive day and a half.
DR. COHN: With that, we're adjourning.
[Whereupon, the meeting was adjourned at 12:35 p.m.]