[This Transcript is Unedited]
Hubert H. Humphrey Building
200 Independence Avenue
Washington, D.C.
DR. COHN: This is the first of two days of hearings of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The committee is the main public advisory committee to the U.S. Department of Health and Human Services on national health information policy.
My name is Simon Cohn. I am the chair of the subcommittee, from Kaiser Permanente. I want to welcome fellow subcommittee members, HHS staff, and others here in person. I also want to welcome those listening in on the internet. I want to remind everyone here that they need to speak clearly and into the microphone, so that those on the internet can hear, as we have our days' proceedings.
Now, the focus of today's hearings is to simply identify next steps related to patient medical records information standards. We, I think, have a draft letter that we will be reviewing after we hear testimony this morning. I think the hope, by the end of the day, is that we will have a pretty complete letter that may need a little more work, but that we come to some final resolution on that.
Tomorrow, we will have a session beginning at 8:30 p.m. and adjourning about 1:00 p.m., eastern time. The focus will be on the status of implementation of HIPAA administrative simplification, and preparing for the annual NCVHS report on that topic.
Why don't we go around the table with introductions.
MR. BLAIR: I am Jeff Blair, vice chair of the Subcommittee on Standards and Security. I am vice president of the Medical Records Institute. I don't think I need to recuse myself from anything, but for public notice and awareness, I am a member of ANSI HSP. I am a member of HL7. I am a member of HMSIS and I am a member of AMIA.
DR. FITZMAURICE: I am Michael Fitzmaurice. I am senior science advisor for information technology at the Agency for Health Care Research and Quality. I am one of two liaisons of the government to the Committee on Vital and Health Statistics, and staff to the Subcommittee on Standards and Security.
DR. KOLODNER: I am Robert Kolodner from the Department of Veterans Affairs, where I am the associate chief information officer in the Veterans Health Administration, and I am staff to the subcommittee.
MR. RISHEL: I a Wes Rishel. I am appearing today as the chair-elect of HL7, about two weeks until I become the chair. In my other life, I am a vice president and research director for Gartner.
DR. YASNOFF: I am Bill Yasnoff. I am associate director for science in the Public Health Practice Program Office at the Centers for Disease Control and Prevention, staff to the subcommittee.
MS. BURKE-BEBEE: I am Suzie Bebee with NCHS, CDC, and I staff subcommittee.
MS. ADLER: Jackie Adler. I am from NCHS and I staff the committee.
MS. WOLCOTT: I am Julie Wolcott with the Institute of Medicine.
MR. BROOK: I am Richard Brook with ProxiMed, also here with NCPDP.
MR. HARRISON: Ed Harrison with Web MD.
MR. ROSS: Jim Ross with Web MD.
MR. BECKLEY: Paul Beckley with the Shears Group.
MS. GILBERTSON: Lynn Gilbertson with the National Council for Prescription Drugs Program.
MR. GUINAN: Jack Guinan. I am here with ProxyMed.
MR. HILDEBRAND: Lloyd Hildebrand, co-chair of DICOM.
MR. CLUNIE: David Clunie, industry co-chairman for DICOM.
MR. CLARK: I am Howard Clark. I work with the National Electrical Manufacturers Association and provide staff support for the DICOM committee.
MS. JACKSON: Debbie Jackson, National Center for Health Statistics, CDC.
MS. WILLIAMSON: Michele Williamson, CDC, National Center for Health Statistics.
MS. FERNANDEZ: Bernadette Fernandez, ASPE, HHS.
MR. COOPER: Todd Cooper, IEEE, 1073 committee for medical device communications chair, and technical director of the IEEE and Medical Device Communications Industry Group.
MS. GUILFOY: I am Helene Guilfoy with Guilfoy Consulting.
MS. HAWKE: Susan Hawke of ASPE.
MS. ALDE: Vivian Alde(?), NLM.
DR. COHN: Thank you very much. I also want to personally thank Jeff Blair, our vice chair, and Mike Fitzmaurice, our staff, for their help and leadership in terms of putting together today's hearing. Obviously, with that, Jeff, I will turn it over to you to make any introductory comments and then lead the session today.
MR. BLAIR: Let me give you my traditional review. I know a lot of you who are here have been through this process, but for those on the internet, just to put in perspective where we are and what we are doing, part of HIPAA included a requirement to the NCVHS to study issues related to the uniform data standards of patient medical record information and the electronic exchange of that information, and to make recommendations to the Secretary regarding PMRI standards.
The NCVHS has done that in phases. The first phase was a framework and a set of guiding principles, which was a 60-page report delivered to the Secretary August of last year. Based on that framework, one of the next phases that was called for was for the selection of specific PMRI standards.
The first step in doing that was for us to look at PMRI message format standards. We have a self-imposed target of February of 2002 for us to make those recommendations on PMRI message format standards to the Secretary. We have gone through that process by adjusting the guiding principles, so that they would be appropriate for message format standards, reviewing that with the PMRI standard development organizations.
Those standard development organizations have responded to the subcommittee during the time from April through June, with responses to a set of questions related to their PMRI standards. In October, we wound up hearing testimony from vendors and users of PMRI standards, and we have begun the process of drafting the recommendation letter to the Secretary.
We have gone through a couple of drafts of that. In the process of doing so, it became clear that a number of the subcommittee members have a few additional follow-up questions to SDOs and the market place.
DR. COHN: Dr. McDonald has just joined us.
DR. MC DONALD: I was downstairs for 15 minutes, too, so I am not as late as it appears.
MR. BLAIR: Okay, let me finish this phrase, and then I would like to have Dr. McDonald introduce himself. So, we are at a stage now where we have asked a number of SDOs to respond to some specific follow-up questions.
I would indicate that I regard this day as a relatively informal process. We have the morning to have testimony from the four SDOs, PRMI message format SDOs, that we have identified. They are HL7, DICOM, IEEE and NCPDP. Before I go into the sequence and take us further, Clem, could you introduce yourself and also identify either any issues that you need to recuse yourself from or any associations that may be appropriate for the public record.
DR. MC DONALD: I am Clem McDonald from Indiana University and Regenstrief Institute. I am chairman of the LOINC committee. I am active in HL7. I am a member of ASTM. I guess that is it.
MR. BLAIR: Okay. As I indicated, this is time for follow-up questions, which we have set aside the morning for. Then, this afternoon, the subcommittee will dig into our draft letter and try to update it to the next highest level, based on the things we have learned or clarified this morning.
As you may have observed, we wound up also sending you all a copy of the draft letter as of November 28. In that draft letter, we did identify that we are considering identifying HL7 kind of as the core PMRI message format standard, with the other three SDOs supporting that in specific market segment areas.
For that reason, I think it would be helpful if we asked Wes Rishel from HL7 to maybe begin to address the questions that we sent to you beforehand. After you have maybe responded to those, if there are other comments or issues, Wes, that you may have, that would be great. Then we can also have questions from the subcommittee.
Then afterwards, as each of the rest of the SDOs testify, there are some issues or questions on how the other SDOs might have either other data or data definitions that relate to the HL7 rim. So, we have asked Wes to stay on so that we could basically get all sides of these discussions in place.
So, if there are no other comments or questions before we begin? Are there, other comments, observations or suggestions? Wes, I invite you to sit back, relax, and share with us the answers to the questions we sent you and any other comments or suggestions you may have for us.
MR. RISHEL: I appreciate the invitation to relax. Wishing that the hotel had an interoperable luggage information system has been an issue for me today. I don't have the handouts I intended to give. Therefore, I am projecting on the screen. I will give an electronic copy for the committee, and I will get handouts made over lunch time and bring them back.
There has been a lot of testimony and presentations here. I will be happy to take questions, but I don't feel a lot of need to do anything but dive right into the specific questions and go forward. So, that is what I am going to do.
MR. BLAIR: I should mention, for the subcommittee members, that I believe copies of all the questions are in your packet. They were also sent electronically to you a couple of days ago, if you haven't had a chance to look at those, as well as the responses that we have received should also be in the packet. Sorry, Wes.
MR. RISHEL: The first question is, is the following framework for dividing the versions of HL7 useful and appropriate, standard schedule for phase out, current standards, and emerging standards. Our response is the framework described in the letter is useful and appropriate, particularly as it is simple.
In other words, we, in building our consensus on this reply among the board of directors of HL7, we toyed with more elaborate and perhaps more precise frameworks. My decision was that simple is better. So, we did not want to change the framework. I will be happy to take questions as I go along. Otherwise, I am just going to move through it.
MR. BLAIR: Did you get the version where the first one was retired, the next one was current, the next one was emerging?
MR. RISHEL: The version of the framework?
MR. BLAIR: Yes.
MR. RISHEL: Yes, I had two versions of the framework. Point one was retired, point two -- okay. Is industry guidance within the current standard section useful and appropriate.
HL7 hesitates to add any complications, but wishes to advise the committee of one or some key points. With regard to the version 2.0 series, we have to recognize that standards adoption in the United States is largely driven by several factors.
One is the implementation cycle of vendor products. So, any introduction of a new standard has a built-in one to three-year time line as those changes go into the vendor products and then reach general availability and then reach a state of being widely implemented.
More important than that is that health care organizations don't change interfaces just to be on the current standard. In fact, locally we say, if it ain't broken, don't fix it. The real philosophy, as seen in most organizations is, if it ain't broken too bad, don't fix it.
There really is good reason for that. It shouldn't be seen as malingering or anything like that. Every organization has a limited budget and limited staff resources. They have to decide and prioritize the work based on where they are going to get some benefit. There is no business benefit to changing an interface just for the purpose of achieving compliance with the standard, and there is no regulatory requirement to do that, and I would hesitate to push for such a requirement.
So, what actually drives interface adoption or standards adoption is the availability of new capabilities in new versions of the standard. We have found, with version 2.0, that new capabilities have arisen from several sources. One of them is a bit unfortunate in terms of the transition to version 3.0.
Virtually every time we have had a good idea with version 3.0, we have put it into version 2.0. So, some of what we initially envisioned as the business benefits of version 3.0 have lost their appeal.
MR. BLAIR: Are you thinking specifically of XML or are there others?
MR. RISHEL: Well, XML, although with XML I would characterize the version 3.0 approach as being superior to the version 2.0 approach. It relates to, for example, variations in specifying how codes are used to more precisely meet different requirements. It relates to added subject matter, any one of a number of areas, really.
It is important to recognize that the current practice in health care organizations that use HL7 is not to standardize on a single version. One of the reasons for that is that HL7 has a built-in -- version 2.0 as well as version 3.0 -- have built-in extensibility models.
As a rule, if a sender of an HL7 version 2.2 message sends a message to another system that is using version 2.3, it should be able to accept that message and process. The reverse is true, with one obvious side comment. If a newer version of an HL7 message comes to a system that is on an older version, it should be able to accept and process the message. However, it won't make use of any of the features that are associated with the newer version.
That capability allows institutions not to have a forced march to the new version, but to adopt the new version where there is project work going on for one of two reasons. One reason would be specifically related to a new feature. For example, HL7, version 2.3.1 had specific capabilities for APCs. When APCs implementation became an issue, there were projects, then, to introduce that version to handle APCs.
MR. BLAIR: Does everybody know what APCs are?
MR. RISHEL: I hesitate. It is ambulatory price category? Is that right? The other reason that they moved to a new version is that, for other reasons they are implementing new software and the vendor of that software has moved their product to be on an upgraded version.
Then they rely on that interoperability not to have a forced ripple effect, where introducing the new version for one vendor means they have to have projects with all the other vendors and the internal systems of the institution. HL7 recognizes that this is the nature of interfacing. Indeed, from the start, they introduced this extensibility mechanism because of that.
DR. COHN: Wes, maybe you are going to address this. I was looking at your overheads and bullets, and I guess I am confused since the version 2.0. Is this extensibility also characteristic of the 3.0 to 2.5?
MR. RISHEL: No, it is not. Let me address that issue specifically. We started working on HL7 in 1987 when I didn't have any gray hair. We were fortunate enough to achieve fairly good adoption and our users made substantial use of the extensibility mechanism.
In the time between 1987 and 1996, when we really began to work on version 3.0, we learned a lot. Probably one of the most important lessons we learned was that we had made a transition from essentially a group of institutions and vendors getting together and talking about what they had already implemented as interfaces, and creating a common set of ideas that had been in the various interfaces and data content and publishing that as a standard.
We have moved from that model to trying to define standards for interfaces that hadn't been built yet, or we were aware that the number of institutions that had such interfaces was limited to the aggressive early adopters.
What I observed, walking through different meetings, was considerable organizational stress based on trying to get to these new standards. Often, we talked through the data and looked carefully at the data definitions and we would find that people were actually violently agreeing with each other, but they didn't know it.
What became clear was that it was important to get straight on the data first, and then talk about functionality of the interface and the actual message design and things like that. That led us to work with the IEEE committee on information modeling and develop the start of what eventually became the reference information model.
HL7 version 3.0 has been developed under that philosophy of you get the data right first, and get concurrence on the data first. We could not have done that and continued with the extensibility for version 2.0. So, whereas the ability to go from version 2.3 to 2.4 is almost automatic, to go from any specific HL7 version to 3.0 involves more extensive use of software mapping and integration and broker tools.
DR. COHN: You almost answered my question. Actually, very specifically, I was just curious about, are organizations going to be able to run a combination of 2.X and 3.X?
MR. RISHEL: Yes.
DR. COHN: Within your organization, related to your second bullet?
MR. RISHEL: Yes, we anticipate that to be the case. We have demonstrated that in our demonstrations at the Health Information Management Systems Society show where, for example, two years ago we had version 3.0 lab orders being translated in an integration broker and sent to a version 2.0 system, and so forth.
It is important to recognize that version 2.0 is customized in most health care institutions through mechanisms within the standards.
So, the way it is applied at one institution is not exactly the way it is applied at another. Indeed, most vendors have built customizable interface software to deal with what are really differences in the underlying environment of the organizations. The local expression is, when you have seen the information systems in one health care organization, you have seen one.
That means that, as we look, going to version 3.0, there is no automatic methodology for adapting these colloquial versions to version 3.0. There needs to be analysis done at each site. This is not atypical of the work that already goes on using integration brokers in drug delivery organizations. So, we see it as not -- we have demonstrated it in controlled circumstances. We see it as a challenge, but the cost of progress.
Certainly, as we have been balloting and getting feedback from version 2.0, this has not been an issue that has been raised extensively in the comments. The fundamental decision we made in 1996 was that, in order to get to the information model we had to, really, after 13 years, make some break in this extensibility, but then to reinstate the extensibility, again, as we sequence through the version 3.0.
Jeff, you may want to -- again, a new member has joined the table?
MR. BLAIR: Could you introduce yourself?
DR. ZUBELDIA: Kepa Zubeldia with Claredi. I apologize for being late.
MR. BLAIR: Could you mention either anything where you feel you need to recuse yourself or associations or SDOs that you are a member of.
DR. ZUBELDIA: I am a member of X12 and NCPDP. I am also a member of AFFEC and WEDI.
MR. BLAIR: Thank you, Wes.
MR. RISHEL: Going back to the prepared remarks, in looking at the specific guidance in the draft letter, we wanted to comment that we do, in fact, intend to create a version 2.5.
There are several reasons for this, but the most important reason is the trade off between urgent priorities and the likely adoption cycle of version 3.0.
We are finding that urgent priorities are most often driven by regulatory decisions and, where there are regulatory decisions, we have to be able to provide a strategy for moving new information content that is implementable through the automatic extensibility mechanisms of version 2.0, as opposed to through a fairly revolutionary change that would affect all the systems in an institution.
Currently, for example, one of the topics that is on the table for version 2.5 is the requirement that is an inferred requirement for the HIPAA transaction standards. The HIPAA transaction standards include data elements that haven't been used in the past. There may be requirements for a clinical system such as a laboratory system, to collect that data at the point of service, and the transfer of that information from the laboratory system to the billing system has been done over the years using HL7.
So, the committee that works on demographic and administrative data is looking at the requirements of HIPAA in that regard for version 2.5.
MR. BLAIR: Do I gather that just from your comment on this is that even though you would be coming up and balloting a new version of HL7 version 2.0, which is HL7 version 2.5, that it doesn't really have different syntax, it doesn't have the characteristics of relying on the RIM and, therefore, you probably would consider it within the context of current standards as opposed to an emerging standard. Is that what you are leading us toward?
MR. RISHEL: Yes, I had difficulty in recommending that a standard that doesn't exist now be a current standard. The sense of this recommendation is exactly what you said, Jeff.
I wanted to just continue on the rationale for version 2.5. HL7 now has affiliate groups, 17 international affiliated groups, one of which is a group of nations in Southern Africa. So, we have affiliates in about 25 nations. A few of those, the affiliates that have been around the longest, have actually gone so far as to have HL7 included on a regulatory basis in their countries.
They have the same need to maintain continuity with the regulatory requirements with version 2.0 for some period of time. Anticipating one of the future questions, I would like to add the comment that we have several projects going on with other standards groups toward making sure that the information transferred is compatible.
As a rule, I would expect that those projects would look at making ostensible changes in the version 2.0 series as well as version 3.0. That is something you can say as a generality but, as a business case, the actual data and other steps.
HL7 recognizes the potential for confusion that we create by continuing to extend version 2.0, while devoting most of our resources to developing and promoting version 3.0. The decision to go ahead with version 2.0 was not made lightly, but was made for the reasons I described. Absent regulation that is certainly stronger than that which is anticipated in the letter, we see nothing we can do but let market forces drive version 3.0. I will speak to that a little more as we go forth.
In general, I think we will find the following phenomenon. Once there are successfully operating version 3.0 interfaces in sizeable institutions, then that will pave the way for more aggressive adoption of version 3.0. All health care organizations tend to be not on the leading edge of adopting new technologies, and they have plenty of good reason for being that way.
Until we can show HL7 version 3.0 as a proven commodity, we expect there to continue to be pressure through our membership toward extending version 2.0. Once we cross that barrier, the advantages of version 3.0, particularly in working through the information model and in going to a superior way of using XML, then that in version 2.0, will lead the membership of its own, simply not wanting to put resources into working on version 2.0 any more.
DR. FITZMAURICE: Excuse me, did I understand you to say that version five will include XML?
MR. RISHEL: 2.5?
DR. FITZMAURICE: 2.5, yes.
MR. RISHEL: From version 2.3 on, we have included a way of doing XML. In fact, it has been demonstrated. It has actually been used in production in some cases.
This represents what would best be described as a transliteration of the old syntax to XML. So, you could literally look at any data field in a version 2.0 message and find a data element in the XML that corresponded exactly.
MR. BLAIR: That is with version 2.4 and 2.5; right?
MR. RISHEL: 2.3, 2.4 and when we do 2.5, it will be with 2.5. Having that capability is important because a lot of application integration middleware these days works better with XML than it does with the older standards.
In particular, it generates accessibility to HL7 in some tools that were designed for other industries but could be useful in the health care industry. When people are looking at XML as providing a more transparent understanding of the data, because of its inherent hierarchy and its labels, when they look at a version that is a version 2.0 message, that is represented in XML, they don't find that characteristic. It is still the old somewhat muddled data model that came out of an early approach.
For example, we have a segment in HL7 that identifies a patient that includes an encounter number. Well, that doesn't make sense from the point of view of an information model because a patient has more than one encounter during even an episode of care. That is what we were thinking in 1987, that that was a perfectly reasonable thing to do. That same modeling error is present in the version 2.0 XML representation.
More important, the data names are derived from the HL7 spec as opposed to being self explanatory in tags. For that reason, we believe that, as the ability to use version 3.0 XML comes out, everyone who is looking to use that XML in some way, where the structure and tags of the XML needs to intuitively reflect the data, they will immediately go to version 3.0 for their XML usage.
The version 2.0 XML will continue to be useful in those environments where you simply have to have XML, but you have to be making very tight relationships with systems that are working on version 2.0.
This line of thinking about 2.5 or future versions of version 2.0 leads us to recommend that we suggest you modify the recommendation, including language supporting the adoption of additional 2.X standards, when they have been standardized by the American Standards Institute, in order to meet the regulatory standards for interoperability with other PMRI standards.
MR. BLAIR: I would like to capture that phrase. Is there anybody who can capture that?
MR. RISHEL: It is on the overhead, and I will be bringing those this afternoon, and an electronic copy.
I am not happy with the language, to be honest. In constructing it, I was bemused about the issue of how to talk about something that isn't there yet as a current standard. The intent of what is to be done is in that recommendation.
If there are questions on that, I would be happy to take them now. Otherwise, I will move to the next of the questions from the letter.
DR. YASNOFF: I want to be sure I understand this recommendation because, within the framework of the letter, we are recommending three different types of standards.
Are you suggesting we include HL7, version 2.5 when approved by ANSI, as another one of the current standards, or are you suggesting we put HL7 version 2.5 as another one of the emerging standards, or are you suggesting something else?
MR. RISHEL: I am suggesting the former, that in recognition of the extensibility of the version 2.0 series, that the language for current series be revised to recognize the inclusion in the current standards of future versions when they are ANSI certified.
The next question is, are the recommendations to HHS within the emerging standards section that are designed to accelerate the development and implementation of HL7 version 3.0 useful and appropriate.
My answer is yes. I don't have any real need to amplify that. I think it is well understood. I would be happy to take questions.
MS. BURKE-BEBEE: This is kind of going back. I apologize. Do you see there being more emerging standards -- and I use that term in a little bit of a different way than the letter -- bottom line, do you see anything more than 2.5?
MR. RISHEL: We have not made a decision to go beyond 2.5 or not to. We think that -- we are, of course, a consensus organization. One of the things I have learned in a leadership position in HL7 is that the smart way to lead is figure out which way they are going and then run around in front of them.
To the extent that we have any influence over our membership, we think that they will naturally gravitate toward version 3.0 as the actual usage of version 3.0 begins to roll out. There are very good business reasons for doing that.
Given the very short time frame that comes from regulatory imperatives, and that could come from specific imperatives associated with recent events, we are not willing to make the policy decision that there will be no version 2.6.
That is why I phrased the recommendation to allow for future versions rather than just specifically for 2.5.
MR. BLAIR: Can I paraphrase my understanding and you just tell me if this is correct, because I think there is a little confusion here.
It is my understanding that, albeit that the category we have there as current is maybe not the most ideal word, that what you are saying is that, if there are any additional versions of 2.X, whether that is 2.5, 2.6, 2.7, whatever they may be, as long as the syntax doesn't change, you are suggesting that we include them with the phrase that you recommended within that second category. Is that correct?
MR. RISHEL: Yes, that is correct. I would just edit that very sightly to say, as long as the established extensibility stays in place. That is probably a little stronger statement that just saying as long as the syntax stays the same.
That extensibility mechanism includes policies that wouldn't correctly be called syntax, where you place new data elements and things like that.
The second group of questions that was sent to HL7 start with the heading, what are the specific interoperability and data compatibility issues related to the sharing of data between HL7 and the following PMRI message format standards.
I have to say now that my answer is deficient with respect to IEEE 1073. Simply in the process of gathering information and recognizing that I am the chair elect and have not had to necessarily be involved in as many things as I will a year from now, I dropped the ball.
I put out some initial inquiries about this, but didn't get any response back. So, officially it says, HL7 has not studied interoperability issues with IEEE 1073.
I apologize for that, and will seek permission to reply later, as I get information.
The second of the listed standards is NCPDP script. A joint effort is underway right now with NCPDP to identify detailed interoperability issues.
Frankly, in light of the intensive effort that we have been having on version 3.0, where in fact we have had to use paid resources to facilitate it and have had to budget carefully how we paid for those resources, this effort with NCPDP has not proceeded as quickly as I would have liked. However, it is continuing and I did talk to those in HL7 who have been involved.
What they advise me is that the issues seem primarily related to the greater complexity of the HL7 pharmacy order, because it was designed for the inpatient environment and, therefore, includes features for intravenous preparations and much more elaborate administration protocols and things like that.
An attempt to create an interoperability between the script standard and HL7 needs to go to the business case.
The third of the questions relates to DICOM version 3.0. The use of DICOM 3.0, as described in the draft letter, there has been ongoing work that supports the interchange necessary to have DICOM imaging systems and other clinical systems that use HL7 as the primary standard to work in parallel.
The ability to attach the identity of a patient or an image from the system that is being maintained in the computer based patient records to the system that retrieves and manipulates images, for background purposes, has been in the standard for a while. There is work ongoing to make it more smooth and well functioning.
So, that completes the prepared answers to the questions.
DR. COHN: I do have one question. You know, in retrospect, we probably didn't ask all of the right questions.
I am just reflecting, as I look at the various versions of standard interoperability -- not interoperability, but coordinations -- you were describing, we mentioned a number of the clinical data standards organizations and others, but we neglected to include X12.
I think the world tends to think that administrative and clinical data standards are different. As I get older and grayer and lose more hair, I am struck by how much overlap there is. Can you comment on this? You can come back to us in written form, if you wish.
MR. RISHEL: The business issues have driven some of that, as I described, in terms of the ongoing work for HIPAA.
Over the years, there have been several attempts between X12 and HR7 to jointly model data. I have to say that data modeling is not so much just a technique you adopt easily. It is more of a life change within an organization.
It is a different way of thinking. We have invested enormously in developing a methodology to get a consensus data model on the committee of numerous -- there are a group of committees, really, with numerous different interests, and each fully believing that they know the absolute truth.
The efforts at data model within X12 appear to me to have been more nascent than those in HL7. We built the whole conversion around it. As a result, we think we have been a little unable to drive forward or exactly how to do that.
We have continued to invite people who have individual memberships in both organizations to participate in the development of a model.
They pretty well have to do that anyhow because of the business relationship between capturing data from various systems and transferring them to the patient.
I know that there is ongoing work in the data modeling community with X12, and we certainly support any type of continuation in that area.
Our goal is to make the reference information model as complete as possible. We may not always take the next step and create a standard based on that information for domestic consumption. That would get us out of our bailiwick. So, there is a division of work between HL7 and X12.
If our information model is right, then when we have messages that are in our domain, they would have related data. The system has to accept those principles and then translate it as required to meet an X12 standard.
DR. KOLODNER: Wes, thank you for the presentation and for the thoughts that you shared. A two-part question having to do with coordination with the NCPDP script.
What would you see as the nature of the coordination? Is it the content and somehow related to the RIM or some other way?
Secondly, you referred to the issue of funding. If funding were to be made available for something like that, would that facilitate the coordination in whatever nature you are about to describe?
MR. RISHEL: I am glad you asked, as you might imagine. This issue of how standards groups best work together is a tricky issue.
It is one of those that involves a substantial amount of what I would call standards group diplomacy.
Every so often someone comes into our space, the space of health care information standards, typically someone who hasn't been around and says, what we need is one organization. Then we could get everything straight.
What I find -- and by the way, I study standards in general for Gartner, not just for health care. What I find is that organizations that take a very wide cut tend to not represent any one faction well within this wide cut, or they tend to support one of the factions over the others.
Organizations have band width issues. The leader of the organization comes from a particular place and so forth.
That tends to generate splinter organizations, because there is not -- this is not a regulatory process. The organizations that feel not well taken care of tend to go off and write their own standard.
By the way, XML makes that easier than it used to be. You don't have to worry about the syntax and you don't have to worry about building an infrastructure to transfer the messages around.
On the other hand, splinter organizations tend to have too narrow a focus and the community of users gets perturbed by having many different standards and there is a force toward consolidation.
We are clearly looking for mama bear rather than papa bear and baby bear here.
The best way to support that is to recognize that the organization that is effective is the one that is addressing the business issues of its constituency.
The business issues lead to different decisions on data content, different decisions on syntax, different decisions on understood characteristics such as this match or real time that aren't always clear from reading of the specification.
The goal of cooperation among the mama bears in this model. It is for interoperability as opposed to the one subsuming the others.
That is a long way of saying that the relationship between script and HL7 pharmacy orders should be an interoperability approach.
That means that we have to be compatible in terms of data content, translatable in terms of syntax and to match in terms of the business function.
So, if the NCPDP transaction has a business function that HL7 hasn't explicitly recognized, we need to recognize that business function and see, can we meet it entirely through mapping from our existing standard, or do we need to modify the standard to modify the business function.
Funding, how could I forget. The resources in HL7 that are sufficiently familiar with the RIM, to accelerate work as opposed to let it proceed at a standard pace, have been -- well, let me put it this way.
We give a closet seminar on how to lie to your boss about how much time you are putting into HL7. In other words, their interest in HL7 has pulled them to commit an enormous amount of time, and it takes a lot of stress when they get back from the meeting, on how to prepare for the meeting that is four months out.
We have found that it is effective to actually pay contractors to develop proposals that then go through the consensus process in the normal way.
Unfortunately, as the incoming chair, I am looking at a deficit budget right now. So, I am not able to do that as often as I would like.
So, yes, funding would help us identify a contractor who could facilitate the discussion and facilitate the process of bringing that into the normal consensus process. After that, we can't rely on contractors because consensus requires the participation of everybody.
DR. COHN: Other questions? Kepa?
DR. ZUBELDIA: I would like to ask you, what are other important issues that we haven't addressed in the letter, or other questions that we haven't asked that we should be asking but we are not?
MR. RISHEL: That is not one that I can say, I will get back to you later on. I want to go back to my opening comment, which is that the most important feature of the letter, as I see it, is that it is very simple and direct.
That is something that I used in preparing my comments and caused me to leave a bunch of things out that I otherwise might have said.
At the level of sort of big topics, it may be that it is being addressed in another committee, but there are two areas where there is an interface between messaging standards and other areas of importance for a national health information infrastructure.
One has to do with codes, and I know that we addressed codes directly, but there is a specific item about the matching of a structure to a code system.
Now, when a code system arises for a specific business function, such as CPT4 for billing, then that is not so much of an issue.
Where people try to adapt code systems for use for other business functions, this compatibility comes in. It is an area that we have worked on extensively in version 3.0 and I think that recognition of the use of codes for different business functions and in different domains has to be addressed very carefully.
The other area has to do with the difference between the national health information infrastructure and technological infrastructure issues, the technology of the internet as the basis for any kind of an information infrastructure.
We are, right now, beginning to see changes in general horizontal standards that bring the promise of the internet and the promise of XML to a state where we might get beyond the hype and really see it begin to be valuable.
That is not that the internet hasn't been valuable, but as a basis for the national health information infrastructure, we are only beginning to see the potential.
One of my personal disappointments in that area has been the lack of an interoperable standard for exchange of data that meet the requirements that go by the acronym CAIN. That is confidentiality, authentication, integrity and nonrepudiation.
The standards that meet all of those requirements are really what is necessary, and what is really recognized implicitly in the draft HIPAA standard.
The internet engineering task force has proceeded at a glacial pace on its EDI standard, and even as it is coming out now, it is behind the technology, in terms of how we would ideally do these functions and what it recommends.
There is another group in OASIS that inherited some more from EBXML that also has an excellent approach. If one of these takes root -- and that really means gets implemented in a lot of middleware products -- then our ability to make use of the internet to, for example, collect all the emergency departments to a national surveillance system, or to collect lab data to be used as a part of a medical management program and so forth, a bunch of problems that are now solved piecemeal on a pairing of business partner basis. It has become just check the box and do it.
Anything that this committee can do to facilitate the promulgation of those standards -- and that involves a process of trying and so forth.
I am very aware of the fact that Dr. Zubeldia and AFFEC is starting up a new study in this area, and that its first study was ground breaking in terms of going to the issues of interoperability versus a previous focus.
I certainly would support that as an important step toward a national information infrastructure.
DR. COHN: Other questions? Mike?
DR. FITZMAURICE: One of the most important jobs, I think, for this national health information infrastructure and for good business practices is to try to harmonize the issues of the variables that we use in delivering health care, paying for health care and monitoring health care, whether it is quality assurance or accreditation.
That means working toward common definitions, track changes over time, maybe with unique identifying code numbers beside each definition, so that when you change a definition of a given variable, you have to change that code number.
It becomes important, then, for standards development organizations to work together on this vocabulary, HL7 we have here today, NCPDP, DICOM, IEEE, X12 and others.
This is a global demand or a global requirement. So, I ask, Wes, in your opinion, is there a need for an overarching umbrella organization to encourage, enforce, a commonality of definitions.
Have you reached the stage of standard development where, for all these standards to work together, you have to begin talking the same language.
It may be difficult, first of all, to use a common vocabulary but yet, in the definitions, we can try to make sure that the definitions are mappable, as identical as possible, across different standard developing organizations, where they have the same meaning and refer to the same concepts.
So, I am asking, is there a need for NCVHS to consider what needs to be done to look over this and to encourage movement toward commonality of definitions? Is this something that SDS can handle on their own by collaboration.
MR. RISHEL: Phrased that way, how can you say anything but work together to do it. It is a motherhood question, but I am going to try here.
It is important to recognize that this issue of focus and attention to business functions that I described earlier, in terms of what is the appropriate size for a standards organization, comes into play very strongly around data definitions.
For example, I would argue that you can look at X12 and HL7 and find some areas where we are very closely matched.
The reason is that those in HL7 that represent a business function have had, as their specific operational goal, gathering information for use in X12 transactions.
So, in many instances, the business need drives some level of collaboration. I have to say that the cross over in membership between these organizations has grown greatly over many years, between X12 and HL7 particularly, as a result of HIPAA.
So, to a certain extent, some progress will happen of its own. That progress will probably be focused on the most important business functions.
The difficulty in achieving commonality is related a lot to differences in methodology and approach. There is -- this is sort of a simple example, but each standards group identifies certain data objects categorically as, these have different names in the information model and other data objects, they have a common element in the information model, and then use codes within the data to say, this is an electrolytes battery and this is a chemistry battery and so forth, rather than having different data objects in the information model for those purposes.
Because any given concept may be represented one way or another in a given model, the mapping is complex, because you have to map code values in one standard to actual elements of an information model in another standard.
So, an effort to promote such interoperability, such commonality, driven beyond what happens automatically in business functions, would take a fairly sophisticated methodology.
As viewed by HL7 -- and I would venture to say that it is viewed by other organizations -- as a deferring resources from getting specific business functions met, that are at a high level of urgency.
For example, could I afford to pay a contractor to represent HL7 at meetings like that. Well, if it became a mandate, we would. We would take that out of some other work.
I would argue that, absent funding, it would have a deleterious effect on meeting the immediate requirements of business functions, which is really what drives us, what really gets people to our meetings, that they have got some problem to solve.
So, I am trying to come to some summary of my rambling now, in my answer. I would say that the requirement exists.
We can facilitate cooperation among the organizations by developing a sophisticated methodology for developing it, but it is not easy, and it is a diversionary thing.
DR. COHN: I think we need to -- Mike, is there a major --
DR. FITZMAURICE: It is a summary. One is that I appreciate not only your testimony on the technical aspects of what we are proposing here, but also the wisdom that you bring in showing us how the standards developing organizations work individually and together, and also your saying that, yes, this is a legitimate need, this is a global need, but since current business needs drive the standard developing processes, it would take an external source of mandate, but you prefer to have an external source of funding to achieve this global funding of definitions.
MR. RISHEL: Right.
DR. FITZMAURICE: Thank you.
DR. COHN: I guess I should comment, this was a major issue during the recent fast track process related to differences in style between UB92 and the X12. So, we have seen this before.
Clem, you have been very quiet. I would like to give you an opportunity and then we will break afterwards.
DR. MC DONALD: The follow up on the next question is this universal anything is hopeless and may be unwise. Every time we try it, we screw up.
When this committee tried it just recently -- we had NDC was going to be the code universally for all drugs across hospitals and outpatient and we had to pull it back. Remember?
The language thing is tough. I think our best bet is, as these organizations collaborate, they will adopt each other -- they will say, you do that, that works well, we will do this.
Some of it is, we don't have any good one. It is not that theirs is good or bad. For example, there really isn't a good clinical drug terminology, at least that I know about, or that people are using. We need to develop that.
DR. COHN: And fund it.
DR. FITZMAURICE: To respond to Clem, I think you are exactly right, Clem. The problem is that there is not a good drug code that would serve these purposes.
So, the government is investing money through FDA to try to develop better codes for this. Whether we get it right is another story, but that is a use of everybody's money, everybody's tax money to do something that is for the common good.
MR. BLAIR: Since we have started talking about NDC codes, right after the break, we will have testimony from Lynn Gilbertson from NCPDP and Jack Guinana, and I think this is a good time for a break.
We started a little late and we took a little longer on HL7 than we thought. May I ask, if it is possible, that we return in 10 minutes, to give as much time as possible to the remaining four testifiers?
[Brief recess.]
DR. COHN: Let me just make a comment here. I think we are all aware that we are running a little late despite our best efforts.
Everybody should be prepared that we will probably go a little bit into our lunch hour. We ask for everyone's forbearance.
MR. BLAIR: Lynn and Jack, we were kind of envisioning one representative from each SDO. However, you indicated that you wanted to have kind of a tag team here.
Essentially, we have three SDOs to cover now. Could you give me some guidance here as to -- Lynn, do you have the lead and Jack is certain specific additional questions, or how did you envision this?
MS. GILBERTSON: That is correct.
MR. BLAIR: Okay, then Lynn?
MR. GUINAN:
MS. GILBERTSON: We welcome the opportunity to speak today. I am Lynn Gilbertson from the National Council for Prescription Drug Programs. Jack Guinan from ProxyMed is also speaking today.
In addition, we do have representation from our membership in the audience, representation from ProxyMed, representation from Web MD and Surescript.
In case there are some questions that come up that we are not able to answer, or they can add additional clarification, they may be popping up from time to time.
MR. BLAIR: Just from a guidance standpoint, I would think if you and Jack could figure on about 20 or 25 minutes, that would give enough time for our DICOM and our IEEE testifiers as well.
MS. GILBERTSON: There were some questions submitted to NCPDP from the committee, that we will be addressing now. I would assume that they are in your packets for you to follow along.
The first question was, comment on the validity of what NCVHS was aware of, that the script standard is implemented and utilized by large pharmacies but not most other pharmacies.
This may be a perception, obviously, because the larger companies tend to make more public knowledge their information.
There are, at NCPDP's estimate, approximately 90 percent of the software vendor physician interface, software vendors, value added networks, that have adopted, or are adopting, this standard.
Of companies that have adopted, there are a significant number of pharmacies that you may recognize, the large ones such as the Walgreens, but also the companies from the provider/vendor industry that you may not be aware of, which represent large pharmacies, small pharmacies and physician interfaces, for example, the ProxyMed environment.
There are also, if you are aware of the PDX, there are approximately 9,000 sites that are script enabled. Of those sites, QS1, which represents approximately 5,000 locations that are large to small markets as well, and the large pharmacy chains that have also implemented it.
There are initiatives as well, if any of you are aware of the new collaboration that has been created between the National Association of Chain Drug Stores and the National Community Pharmacy Association known as Surescript System, this represents not only the large pharmacies but also the community pharmacies in a collaborative effort to bring forth the script implementation for those markets as well.
MR. GUINAN: I would just add that the companies that were mentioned, the software companies on the pharmacy side are in a production environment, providing EDI transactions on a daily basis with the physician community.
As well, there is another organization, TechRx, which represents, from their numbers, 22,000 pharmacies, from independents through large chains, that have also adopted the script standard.
It is not in production today with their stores, but I think it is equally important that they have adopted that standard. So, it is the one that will be used as they role their function out to their stores.
MS. GILBERTSON: The next question was about the current standard, which version. The currently used version is the script version 1.5.
NCPDP is recommending that the newest version, version 4.2, be recommended for PMRI for the script environment.
However, I was interested, in the draft recommendation letter, there are multiple HL7 versions recommended.
So, it is very possible, if the committee wishes to recommend the current version 1.5 and the version 4.2, which will be completed very shortly as two standards to name, that is perfectly acceptable.
There was a question, how detailed and comprehensive is the script implementation guide. If you like, I can share copies.
It is a 225-page implementation guide. So, it is not a small piece of paper to read.
In addition, there is a script standard which is the message syntax and the field definition at the message level.
The script implementation guide goes through a lot of the business functionality. Script not only handles new prescriptions, it handles refill requests and responses, change requests to new fills, compliance transactions, and it can be done, as the membership requested, in an online real time environment.
So, the implementation guide discusses, in quite a bit of detail, the diagrams of how the conversations take place technically.
It goes into examples that are business examples with field definitions, obviously showing real prescription information-like data. It shows how it flows diagrammatically. It shows syntactically, and then follow-up explanation.
The implementation guide also goes into detail about each field, each segment and each message, a different layer to explain not only the business, but the technical, so that an implementer might be able to get some benefit from this documentation as well.
There are also some external code sets and internal code sets referenced in it as appropriately, and frequently asked questions.
Does NCPDP script specify the use of text or codes to identify drugs? I thought this was an interesting other side question.
Basically, the script standard was developed to handle both. Current practice is that a physician writes on a pad, and writes text information out about the drug, the dosage, all that information.
So, the script standard does handle the script definition of fields for the drug name, the strength, the quantity, obviously text versus numeric as appropriate.
It also handles the code sets, the NDCs, the UPCs, the HRIs, the smart keys, the GPCs, all the different values that you might use to come up with to identify an item that is being prescribed.
It is up to the business practice how they wish to implement. For example, the doctor might write it down in text form, but how it is entered into the system is up to how that software vendor chooses to implement. It may be pull down lists based on their most commonly used prescriptions.
Then it can be transmitted. Obviously, the pharmacy, because of billing for claims, dispensing a prescription, is using the NDC codes as appropriately for that part of the conversation.
Additionally, as conversations go back and forth between the pharmacy and the prescriber, the pharmacy system has not only the information as it was sent from the prescriber, but also has the information as captured in the pharmacy system.
If a pharmacy wishes to follow up on a refill, to ask for more, for example, and wishes to send back not only what was prescribed but what was dispensed, they can provide that as part of the communication, just as further clarification and facilitation.
MR. GUINAN: Just a quick note. Of the about three million online prescription transactions that run through ProxyMed's network yearly, only about 25 percent of those messages include an NDC code to identify the drug.
On a practical use basis, free text has been the primary way to move these messages. The lack of an NDC code does not preclude a functional system, from a business perspective. It just limits the functionality of the system.
We could get started with an overall system and a standard that used free text for the drug names. It just limits functionalities like drug interacting checking at different points.
If a pharmacy sends a refill request for a certain drug back to a physician's office and they have an electronic medical record system, if it is identified by some code -- let's say an NDC -- then that physician office system can perform more functions like more drug interaction checking at the point of care.
Without the NDC code, the system can't positively identify that drug to perform these systematic checks.
I guess my point is that the lack of a universal code set or specific ID for drugs does not preclude the use of this system, but it does limit the functionality of the system. So, it would be a huge benefit to have one in the future.
DR. COHN: Jeff, can we ask questions at this point?
MR. BLAIR: Yes, are you both finished?
MS. GILBERTSON: Just with that question. There was a question about what is the status of negotiations between NCPDP and HL7.
First of all, strike the word negotiation. This is a collaboration. I think Wes did a real good job of answering that.
Obviously, we are both run with voluntary membership and right now, to be honest, HIPAA and the clarifications from the transactions and code sets and the privacy regulations are occupying a lot of our membership's time.
There is a considerable desire to continue the negotiations, the collaborations, with the different organizations.
We had a conference call in September with HL7, the pharmacy SIG, and NCPDP shared the script standards and implementation guide with the participants.
We recently received version 2.4 of HL7 standards, and we are going through those now, trying to get familiar with the sections that are important to what this collaborative effort is going to be doing. That is the up-to-the-minute status right now.
Our short-term goals for this are to understand the nomenclature. As Wes did describe this morning, you have got to get to the point where your widget is a widget is a widget.
I think we are much closer than maybe the public understands when it comes to our data and our definitions, and it is just the mapping of that, or the understanding of that, that takes the time.
We are going to spend time on that as a short-term goal, and the long-term goal is to look at mapping the interoperability, as he mentioned this morning.
There were a few other questions that were submitted under a separate e mail that we can go over just briefly.
The first question is, how many physicians are you aware of that are using the script to send new prescription messages to pharmacies.
MR. BLAIR: Lynn, just let me make a clarification. The questions that you are going through now were sent to ProxyMed, to Medcomsoft, and Allscripts, who were the three folks who testified to us on October 9, who indicated the greatest use of NCPDP scripts, just so other folks are aware of this separate set of questions.
MS. GILBERTSON: Do you want to take that?
MR. GUINAN: Sure. In response to the first question, which is how many physicians are you aware that are using NCPDP script standards for new prescriptions, I make this inclusive of other types of script messages as well. I make a point about the number and kinds of transactions in a second.
We have approximately 5,000 registered physicians on our network. I would imagine the number to be somewhere between 5,000 and 10,000 physicians who are actively using the script standard to transmit prescriptions electronically.
I think more important, though, is to note that the software systems that these physicians are using represent a much larger universe of physicians.
Just because only 1,000 physicians who use a certain product are active today, there are another 125,000 physician who use that same software product that could be active, and who would end up using the same standard.
So, the point is that there are relatively few physicians active today. The software they use, though, represents a much larger universe.
I would estimate that universe to be well over 150,000 physicians when you combine those software companies, on the pharmacy side.
The next question is how many pharmacies. Let me address that. There are about 20,000 pharmacies between the software companies that were mentioned a minute ago, that can participate if they want to.
Their software vendors are active on a network using the script standard today. The TechRx organization that I mentioned, not active today, representing 22,000 pharmacies that could, though, in the future, and their organization has adopted, to my knowledge, these script standards.
That would make the number of pharmacies well over 40,000 that would have adopted, in one way or another, the script standard out of the 50,000 to 60,000 pharmacies that make up the universe. So, it has been widely accepted, if not used so far.
I will just keep going down the questions. The next question, what versions of NCPDP script are being used for new prescriptions.
I will interject here the point that the script standard is composed of many transaction types, not just new prescriptions.
There is a lot of attention given to the new prescription process in the media, elsewhere, and even many software companies, because it presents the opportunity to fix medication errors and a lot of problems that are talked about, although the utility of the script standard goes far beyond that.
In fact, there are many administrative processes that go on in the business between physicians and pharmacies that represent a huge amount of phone calls today.
So, one of the biggest problems in physician practices and pharmacy practices today is the number of phone calls between each other and the need to find a way to move between these versions.
These do not represent major syntax changes to the formats, although the version numbers might be broad between 1.0 and 4.2, there are not huge syntax changes. So, there is not a large amount of work to move between those formats.
Just moving quickly through, I already addressed new prescriptions using NDC codes.
So, any other comments, I actually have three brief comments that are outside those questions. One is for you all to consider the possible conflicts with state laws.
The practice of pharmacy is governed by state law. Many of these statutes dictate the content of a prescription, the way that that prescription may be transmitted, who can transmit the prescription messages.
So, the work being done by NCPDP, or the implementation of the standard, has an overlap with state law.
So, a national scope federal mandate of some specific set of rules, and particularly if it went beyond just formats but into any other sorts of policies or processes, could possibly conflict with some state laws.
Some states do not allow the electronic transmission of prescriptions by law. So, there might be some consideration that you need to make there.
Similarly, the DEA has an ongoing effort that does overlap the discussion that we are having with NCPDP, and that is working on standards for data transmission and security of online prescriptions.
NCPDP is in conversations, has a dialogue, is cooperative with DEA on this. Certainly there is an overlap.
So, your organization needs to be careful that those overlaps don't conflict. It sounds like the DEA is making strides and is about to put forth at least recommendations, if not start mandating certain standards for online prescribing. I think that covers my points.
DR. COHN: Are you ready to take questions?
MR. GUINAN: Yes.
DR. COHN: I guess I am scratching my head a little bit. Let me just ask one or two questions. I am sure others will have additional comments or questions also.
Obviously, you mentioned 1.5 and 4.2. To a non-NCDPD person, that sounds like a fairly wide difference there.
The reason I am mostly interested in this particular standard has to do with patient safety issues. Now, can you describe for us, are there any issues, one versus the other, in terms of patient safety considerations?
MS. GILBERTSON: The difference in the versions? No.
DR. COHN: So, they basically have the same features. I presume, in either case, there would not be automatic drug-to-drug checking, because you weren't using a coded terminology, except for refills. Of course, you don't have a drug terminology for that anyway, for prescription writing, at this point.
MR. GUINAN: I would say that either version of the standard would equally support those patient safety issues.
Those are much more issues of the trading partner systems and their functionality, but the NCPDP script standard will support the transfer of the information, too, will support it.
MS. GILBERTSON: Basically, the difference between the versions really is additional codes that were added as we moved forward.
This table was associated with 20 values. Twenty-five are now on it, or things like that. Obviously, the more robust -- you have to go forward. So, the version 4.2 would have the most comprehensive lists of those. It is not like you cannot perform the business function by using 1.5.
DR. COHN: You have seen the letter that we have produced. We tend to think of things as current standards and emerging standards.
I am a little confused about where are these versions? What is your recommendation on that? Is 4.2, since that is so close to balloting, will that one be the standard, or is it an emerging standard?
MS. GILBERTSON: I guess it is the same question that Wes -- it is the standard, go forward to, and it will be adopted by some of the major players that are now focusing their efforts.
The recommendation is, if we have to pick, would be 4.2. Obviously, you want more functionality than a little less, even though there is not a big difference between those.
Every time we add a value or whatever, we increase the version release. So, it is just a mechanism for the technical side, to know which dictionary you are playing with.
DR. COHN: I think I will let Jeff follow up on that one.
MR. BLAIR: For clarification, I think I can understand that 4.2 would be maybe categorized as maybe an emerging standard.
The current standards, here is where I am confused. It sounds to me as if both 1.5 and 3.1 are both current, but it seems like there is a skip. Can you help me sort out how we should handle that?
MS. GILBERTSON: Maybe it is the terminology of an emerging standard versus an emerging version. The standard is stable. It is comfortable. It is used.
The fact that it has had enhancements is really a version. I guess that is the part I am wrestling with. I really can't say that 4.2 is an emerging standard because it is built on something that is current and being used. Does that help?
MR. BLAIR: It does a little bit. Originally I had thought that version 3.0 or 3.1 was considered to be the latest version that you have. It sounds as if most folks have implemented 1.5.
I wasn't sure how to refer or for us to understand the difference between 1.5 and version 3.0 or 3.1.
MS. GILBERTSON: When we originally submitted the response to the questionnaire, the PMRI questionnaire, we did put version 3.1 as the standard at that point.
Since then, we jumped from 3.0 to 4.0, because the change was a data element and that caused a new version, a version 4.0 environment. I think it was adding an e mail address or a telephone number or something like that.
That caused our rules of dictionary increase. So, 4.2 is the recommended latest version that we would like to see.
MR. GUINAN: To Wes' comments before about the dynamics of adopting a new version, what happened was that organizations put 1.5 into use.
There were discussions and then the 3.1 version came out, but no new companies of any size came into the business and so adopted it.
So, in the meantime, 4.2 is coming out. So, the organizations that are doing this today all came in at the time when 1.5 came around, and no new organizations came around at the time that 3.1 was adopted.
As new organizations like Surescript, which is brand new comes in, they will adopt the latest one, 4.2, and they will drag the rest of us up with them as they get big partners.
I would suggest, though, from a practical standpoint, that if there is a concept of current and emerging, that 1.5 is the currently used version of the standard.
It will take companies a little while to transition to a newer version, even though I did say before this will not be a large problem for us.
There will be time, and also Wes mentioned very well about the development cycle, the time to get products out into the field.
I would suggest that 1.5 be considered the current version and that the 4.2 certainly is emerging, as it becomes the voted on, accepted version, but that label could change.
MS. GILBERTSON: Emerging version.
DR. ZUBELDIA: I have a comment and a question. The comment is that when other standard setting organizations change the major number every time they add a field or change a field, we would have, instead of version 1040 of HIPAA, it would be like 56,000.
MS. GILBERTSON: Duly noted.
DR. ZUBELDIA: I am amazed at the stability of your standard. I would like to get a clarification. You mentioned the implementation guide that has 235 pages.
What version is that? Is that version 1.5, 4.2 or somewhere in between. Then I would like to ask about other versions.
MS. GILBERTSON: I think the very first one that came out was about 200 pages long, version 1.0 in 1996.
DR. ZUBELDIA: It is now for version 4.2.
MS. GILBERTSON: An implementation guide goes with each of the standards.
DR. ZUBELDIA: What about other standards? You mentioned the DEA is coming up with something on the security side that may have some prescription implications.
I am sure there are some companies using XML and they have gone public saying they use XML prescriptions. I am sure there are other companies using private standards. To what extent is that a problem? Are there lots of other standards out there for prescriptions, or is everybody adopting the NCPDP script?
MR. GUINAN: I would say it is almost universally accepted. I have not run across a company that has chosen to use a proprietary standard in quite some time, in a number of years, in fact.
XML, though, is being used. In fact, we have adopted an XML implementation of the NCPDP script standard. We have taken the segment and field identifiers and made them tags in XML.
For companies that want to use XML documents as opposed to EDI formatted messages, we exchange those today through the network and then map the XML implementation back to an EDI implementation, I will call it.
That did not prove to be a problem. The syntax of the script standard was easily implemented in an XML document type definition and schema.
DR. COHN: Can you come to the microphone? Did you have a question on this issue or something else?
MS. WOLCOTT: It is on this issue, but a little bit different.
DR. COHN: Okay.
MS. WOLCOTT: My name is Julie Wolcott. I am with the Institute of Medicine. We are just beginning a study on data standards for patient safety reporting systems for adverse events.
As you know, medications are a very big concern in that regard. I was wondering if you could just say a few words about how you see the work you are doing on standards here playing into an adverse event reporting system, particularly with regard to near misses?
MR. GUINAN: I don't know. So, I will have to check, unless someone here knows the exact version, where a segment was introduced that would allow the transfer of documentation of adverse events to be included in the message, to go between the physician and pharmacy or the other direction.
This would allow it also to be captured into any other system. So, in 4.2, one of the changes that made it go up to 4.0 instead of 3.0 was the introduction of segments to include documentation on drug adverse events to be exchanged.
MS. GILBERTSON: It is a DUE composite that has reason for service, professional service codes, outcomes and interventions. Peter, do you want to add something?
MR. HARRISON: Peter Harrison from Web MD. That allows the pharmacy to transmit that information back to the physician and vice versa.
Far and away, the biggest advantage of having the script standard is that it eliminates the handwritten prescription and you lose all that uncertainty with legibility and misinterpretation of doses and so on.
Doing the prescriptions electronically almost always means that you are putting it into the system that has or can have the ability to do drug interaction checks and dose/age checks, dose/disease, all sorts of things. That is the major safety advantage of the script standard, is its simple use.
DR. KOLODNER: I had a related patient safety question. Is there an existing transaction in the standard that allows for transmission of a profile of all the medications a patient is taking?
Essentially, you can send in a query, either with a new prescription or without a new prescription saying, I would like all the medications that a particular patient is taking, and then you get back a transaction which lists all of those, to facilitate either deciding on a new prescription or evaluating the new prescription in terms of interactions with existing prescriptions?
MR. GUINAN: That is a pending and under discussion transaction type, although there are implementations of the existing transactions for this.
ProxyMed has implemented a profile request and response transaction set based on the existing transaction types.
Now, it goes outside the standard slightly because we have modified the transaction type field. The basic fields, you can imagine, in a new prescription request are the same as you would get when you got back the list of the 10 drugs, so that it well facilitates.
So, the creation and adoption of this patient medication history request and response is not outside. In fact, it is right in line with the work that is going on with the current transaction discussions.
DR. MC DONALD: Just a clarification for the question before that, you were asked on near misses. This is a community pharmacy to office transmission, where you don't have the big drugs being used as often as an inpatient where people drop over.
I had two questions for the panel. One was, you mentioned three different vocabularies and I wasn't aware of that many, maybe for. Could you just clarify those again? That is one question, and I have a second question.
MS. GILBERTSON: The NDC codes, UPCs, the health related items, the HRIs, then you have the smart keys, the GPCs, all the things having to do with the generic nomenclature.
DR. MC DONALD: Who does smart keys?
MS. GILBERTSON: First Data Bank? I need my list. There is a list of probably seven or eight different codes that can identify the item being dispensed or reported on.
MR. GUINAN: As well as First Data Bank, which then acquired Medispan, but they still have separate data bases.
Even inside those companies, they have multiple data bases that provide codes at different granularity levels. I don't have the exact names here in front of me, but if you go to those organizations, you will see them.
DR. MC DONALD: Does a physician's office have to have agreed upon the same set of codes as the pharmacy, or do they have enough cross translating that they can get that?
MR. GUINAN: There are cross reference tables that are not -- there are cross reference tables for all of them. They are not 100 percent accurate.
If they are at different granule levels, then there is an opportunity for error. So, that is not the preferred mode of operations, but yes, there are cross reference tables.
DR. MC DONALD: The last testimony I heard, I got the sense that there was actually a very small number of physicians writing on them. Is that correct?
You just mentioned a lot of offices are connected. Are physicians actually entering the prescriptions?
MR. GUINAN: No, the vast majority of these prescriptions are being done in a mode where the physician, as opposed to writing on a prescription pad, is writing an order out on the encounter form or on the chart, much like a lab order or a radiology order.
Then one of the physician's staff acts on that order, and they then provide the data entry, a nurse, a nurse practitioner or medical assistant is interfacing with the system.
When we are speaking about refill authorizations, the vast majority of the work is done by the medical records departments, that prepares everything, pulls the chart and then goes to the physician with a nice printed chart, yes/no, yes/no.
Actually, today, with the sort of lack of success, I will call it, of the hand-held initiatives, which would have brought physicians in, no, primarily the physician's staff or those interacting with the systems.
We have seen this changing as the demographic of the managing physicians and practices is changing now, mostly the age demographic and the physician making the business decision in the office becomes more computer savvy.
We are seeing a trend in that direction, but by no means a major shift.
MS. GILBERTSON: Bob, did you have something?
MR. BECKER: I am Bob Becker with Surescript. The comment on getting the prescription, the assumption is that there is one place they are all kept and they are not.
You have patients go to multiple pharmacies. You have patients that pay cash for some prescriptions and some prescriptions that are paid by a third party.
If a doctor was to go out and get a query, where would the doctor do the query to find all the medications that a patient is taking. That is one of the big issues in the industry right now.
DR. KOLODNER: I agree, but my question was, assuming there is some place you can go or there is some way that you can construct the information or even that you can get partial information, the question is whether there is any transaction that will allow you to capture that information.
I agree, that the issue of how you are sure that that information is complete, et cetera, is a difficult issue. If there is no transaction, then it doesn't matter, because you can't send it.
DR. YASNOFF: The other thing is, talking about safety very quickly, all of the pharmacy management systems do drug to drug interactions, drug to dosage, drug disease type interactions.
Even if the prescription does not come in with an NDC code, when the pharmacy puts it into their system, then it is translated to an NDC code.
That is always where -- it may be done other places, but always within the pharmacy -- you will get your drug to drug, drug disease, drugs to dosage interaction. That is the last stop, but it is always done there.
DR. COHN: I have one more question and then hopefully we can move on to the rest of the testifiers, lest we be here until 3:00 o'clock.
This may be having to do with my own ignorance, but as I understand it, in the inpatient world, HL7 handles the interaction between the inpatient pharmacy and the pharmacy, whereas in this case we are talking about a different standard having to do with an outpatient.
Is this going to be a problem? Is this going to be confusing for pharmacists or for providers or for anybody else?
MR. GUINAN: We have actually in the past, although it is not in use today, done the mapping between an HL7 prescription order and an NCPDP script prescription order.
An outpatient prescription can be viewed as a subset of the HL7 inpatient prescription standards. So, all the fields necessary to create an NCPDP script transaction are present in the HL7 standard.
There is sometimes a business confusion, in that the clinicians in the inpatient setting might want to send more information, or they are used to sending more information along than an outpatient pharmacy had to handle in their system.
There is no problem in viewing the NCPDP standard as an interoperable standard that can be mapped to, or I should say more from, the HL7.
Since it is a smaller subset, it doesn't contain all the data elements necessary to create a full HL7 prescription record from their viewpoint.
Certainly, a prescription coming from an inpatient setting to the outpatient pharmacy is the setting that we work in, and that is certainly a viable scenario today, with the standards the way they exist.
DR. COHN: I have just one final question to ask you. I just ask you about the letter. I think one piece that I am still left a little confused about -- and you can either respond or send us written information -- has to do with how we characterize the 1.5 to 4.2 family of standards.
As best I can understand -- and it is not just one question. As best I understand, they are all sort of existing standards.
I don't hear anything there that is unique enough, that has enough superior value that it is really an emerging standard.
By the time this thing comes into use you may have a 5.2 or a 7.2; is that right?
MS. GILBERTSON: We would be moving forward, right.
DR. COHN: Now, are all these standards, 1.5 to 4.2, basically interoperable?
MS. GILBERTSON: Yes.
DR. COHN: So, backward and forward compatibility. Then I think we would have to say they are the currently existing family. So, thank you for that clarification.
MS. GILBERTSON: You don't usually move forward compatibility.
DR. COHN: Backward compatibility. Thank you.
MR. BLAIR: Could we have IEEE as our next presenter? I think that is Todd.
MR. COOPER: My name is Todd Cooper. As I said before, I am chairman of the IEEE 1073 committee for medical device communications.
I am also technical director of the IEEE industry standards and technology organization, medical device communications industry group, or the IEEE ISTO and DCIG.
I am glad, actually, that I am going on later today, because I am from San Diego and starting to wake up now. So, this is about the right time for me to start being coherent.
There are a number of questions. I assume that you have had opportunity to review my written responses. So, I will give you a quick summarization, and then fill in with any specific questions that you might have.
The first question had to do with market acceptance by major vendors and user of the IEEE 1073 standards.
As I indicated in my response, 1073 is well classified as an emerging standard. There are some parts of the standard that have existed for a number of years. There are other parts -- like the .3.2 standard, the 1073 standard -- that is a software framework and overview.
What we are looking at is a full stack of communications, from the physical layer up through the application layer. So, there are different components of that, that are just now emerging and coming out.
As I indicated here recently, as recently at December 1, I think Biosys Health Care, which is a major ventilation company, announced a product to be available within the next six months on the market, supporting a full 1073 interface.
So, when we are talking about emerging, we are talking about products just now coming to market to support this standard.
Also, within the NCBIG, which is a non-profit organization run through IEEE specifically to try to advance and complete these standards, there are major health care or medical device contributors or participants in that organization, including Abbott Laboratories, Baxter Health Care, Gambro, GE Medical Systems, Phillips, Seimans, Space Labs.
Clearly, there is a significant involvement and interest within those major device vendors to get these standards in place and standardize device communications.
Another indicator of acceptance is that the IEEE 1073.3.2 cable or transport, lower layer transport, was recently incorporated into the NCCLS point of care test standard, which should be out very shortly as a transport to be used for the medical device link.
Also, I might mention that we have made a concerted in the last few years to utilize and incorporate in our standards off-the-shelf technology, for example, that are readily used in the industry, and not try to reinvent the wheel, which was done for a number of years in the past.
A good example would be the utilization of ERTA-based standards, RS-232 signalling, RJ45 connectors, common components that you would find both within a hospital and IT departments today.
The second question had to do with implementation guides. Specifically, I mentioned that, through the NBCIG, we were currently engaged, and had been for a couple of years, in a number of prototyping and demonstration products.
These take specific medical devices, ventilators, infusion pumps, patient monitors, and do an implementation.
The documentation that results from that shows you how you would put together an implementation. It many times includes software that might be used, specific PDUs, down to the bit and byte level, and the standards that are leveraged and what not.
I would say that, in one regard, implementation information is contained within the documentations coming out within those projects.
Also, the IEEE, the .1.3 framework and overview document for medical device specializations gives you also implementation guidelines for how you take the generic information model, the nomenclature, and marshal those into specific implementations. So, that is another example of how we provide that.
What we don't have, I think, today is a specific project for an implementation guide, and I am not sure exactly what that would look like.
Obviously, we are open as a group to provide that information as a need is seen within the industry. Right now, we are providing information that those who are implementing the standard feel like they need.
As those implementations come along, we are generating that and making that publicly available.
The third question had to do with plans to develop conformance tests for each device-specific standard within the IEEE 1073.1.3. I think you meant device specialization standards; for example, if I had a ventilator conformance test for that ventilator.
As I indicated in my response, each one of the standards in this family includes implementation conformance statement guidelines, a set of tables which you fill out whenever you have an implementation.
It indicates, what are the mandatory components that you have implemented. What are the optional components that you might have included, and what are any extensions that you might have added to that.
So, every implementation will have a set of ICS tables which will define how it communicates, what has actually been put in the device.
Through the NDCIG, we anticipate providing --
MR. BLAIR: Todd? One thing. I know it was a struggle for me a little bit, because I wasn't familiar with many of the acronyms. I think it will help is, as you go through, as many of these, if you could let us know what they are?
MR. COOPER: Which one specifically? ICS? I think that is was the last one.
MR. BLAIR: Yes, that was one.
MR. COOPER: Implementation conformance statement. That is also known as PICS, a protocol implementation conformance statement.
These, I might mention just to digress for a second, we spent the last year putting in a fair amount of effort harmonizing IEEE activities internationally, working through our partners over in Europe.
The SEN technical committee working group 4, who has two standards out right now that much of our work is based on, which is SEN ENB 13734 and 13735.
The information in those is now being partitioned and rolled into different 1073 standards.
Also, we worked to harmonize at the ISO level. For example, all the document numbers, document names, standards names, will be identical between what you see in IEEE 1073 and what you see at the ISO level.
There, we are working through ISO 215, working group 2. The numbering there would be 11073, dash, and then the same kind of number.
I say that to indicate that with the SEN standards, 13734 and 13735, those also have these ICS tables, these conformance statement tables, built in for the generic components, for example, the domain information model.
So, we start at the very abstract level. We provide the ICS statements that need to be in there, and move that all the way forward through the device specialization standards, which are being called out here in this question.
As I was about to say, the NDCIG is anticipate to be providing profile registration services. So, these will be publicly registered profiles that you can build against or buy against.
To that end, there has been a considerable amount of discussion with respect to conformance testing and certification testing against those profiles.
In fact, that is a major topic of discussion at the upcoming meetings in San Diego the second week of January.
A number of companies also have expressed interest in possibly providing those conformance test services. What I don't think we have right now is anyone who is actively pursuing definition of a conformance test. So, standardized performance tests that could be used.
I think the next two questions have to do somewhat with harmonization efforts. The next question is, specifically, what issues are being addressed, or need to be addressed in harmonizing IEEE 1073 standards with HL7 standards.
It is too bad, I think Ross had to step out. I was going to give him an update on the activity that we have had with the HL7 group, which has actually been a fair amount.
We have met now a number of times with the HL7 LAPOCTSIG. I think that is laboratory automation point of care test special interest group, if I remember right. I am not positive about that.
It is specifically identifying communication scenarios, messaging scenarios that would be required to establish interoperability between environments that utilize 1073 type of messaging and environments that utilize HL7 types of messaging.
There was an extensive study -- I think my response in the next section -- which has to do more with nomenclature and data definition -- harmonization, especially comparison against the RIM.
In there, I mention a short strategic study that was done within SEN TC 251 entitled, Strategies for Harmonization and Integration of Device Level and Enterprise-Wide Methodologies for Communication as Applied to HL7, LOINC and ENB-13734. That is one of the standards that I mentioned before, that contains a domain information model.
We reviewed that at length at the Salt Lake City meetings last October. Stan Huff was there. He actually went through the 200-some-odd page document and said all of the findings in the document were pretty much on target.
The end result of the document -- and Michael, I think this addresses your specific interest is -- before, we were talking about trying to provide some kind of consistent mapping between the 1073 domain information model, DIM, and the RIM, or between the nomenclature that we use on the device side with LOINC.
The results of this study basically indicated that, although you could do it, it would be a fair amount of effort, especially at the nomenclature, just because of the different nomenclatures that underlie the way the nomenclatures are designed.
As a result, the better activity is to get together, identify messaging scenarios in which information needs to pass between these two environments.
Then, out of that, identify what are the mappings that are needed at the model level, what are the mappings that are needed at the nomenclature level, and then identify those and go and generate those. In essence, that is what we are doing now through our activity with the LAPOCTSIG.
There are some areas which are clearly, even on an enterprise level, more of interest, or more germane to the 1073 types of protocol messaging design.
For example, if you were doing a remote control of a ventilator as well as real time wave form data display, that is specifically the kind of thing that we are trying to do with that set of standards.
There are other areas, clearly, that are more germane to the interests here, where you are talking about exchanging information with HL7-based kinds of applications.
For example, taking snapshots every hour of a device activity and configuration and rolling those into the patient record, or being able to retrieve prescription data, for example, if you have an infusion device, being able to go out and retrieve that, and push an order or patient information, maybe patient ID, back down into the device.
There are those scenarios where obviously that has to happen. So, just to pull this one together, there is a fair amount of activity.
I know Stan Huff has given it the thumbs up and we are pursuing that actively between the LAPOCTSIG and the 1073 committee.
I think the last one was, how in the world do we refer to this pile of standards. Yes, 1073 standards, or family of standards, is fine.
You might also consider talking about ISO/IEEE standards for point of care, medical device communication, which is the moniker that is actually on all these standards now. All the titles have that at the beginning.
DR. COHN: Todd, maybe I should start with sort of the first question here. I am just perhaps reflecting a little bit.
Maybe I have been around this a little too long. I can actually remember seven, eight, maybe even 10 years ago, being aware of the 1073 transaction.
I guess I am scratching my head at this point, 10 years later, you describing it as an emerging standard with apparently little market activity.
Maybe I am misunderstanding your testimony. You obviously describe -- you said, there is no extensive market activity possible. Is this still being worked on? Is it not ready for prime time? Maybe you could explain to me why it is even an emerging standard as opposed to nothing we should consider.
MR. COOPER: After all these years, absolutely. There are a number of reasons. Historically, I can tell you that the primary reasons why, from my perspective -- this is one individual's perspective -- how we got where we are today is, the first five years -- we are basically on our third generation, if you will.
The first five years were spent with the medical device companies arguing at great length about minutiae. What should the baud rate be. Should we have stop bits or start bits. What PIN, what signal should be on what PIN, all those kinds of questions.
It ate up an immense amount of time, which almost pulled the standards down, and almost pulled it to where the activity was almost folded, I think, in the early 1990s. They were considering that.
Another company came in and said, no, let's see if we can't progress this and push it forward, and they tried that for about another five years.
The issue there was that the standards that they got through were very expensive, very much proprietary, didn't at all address the needs of the companies that were there.
As a result, there was no market acceptance of those standards because of the fact that nobody was interested in putting hardware within a medical device that cost $200 or $300 for a simple communication or where that was a major component of the device.
When that company decided it was tired of pushing that agenda, those same manufacturers, the ones I mentioned earlier, that currently belong to the NCBIG, got together and said, what are the barriers for us getting this stuff completed and out to market, because we have very real business needs that we are trying to address.
As a result, they quickly said, we need to get a new transport. We turned that transport around in about a year. I think that came out the first part of 2000, end of 1999, 2000, and that is the transport I mentioned has also been accepted by NCCLS for use there.
MR. BLAIR: Could you define transport? Are you talking about syntax?
MR. COOPER: I am talking about an ISO several-layer communications model, layers one through four, so the physical, the data link, the network and the transport layers.
Typically, you might think the TCPIP or UDPIP are other examples of transports, making that connection with the device.
Coming up with something that has supported legacy devices, that was low cost, that used components that were off the shelf, like I said, RJ-45 connectors, and CAP-5 cables, the same stuff that you have on your own computer for an ethernet link.
What happened next -- like I said, we spent a lot of time over the last year now -- is taking standards which were about to go to final ballot and the implementations were about to be done, wherever we had major issues internationally.
We decided, instead of pushing that through to the IEEE, we would try to harmonize the effort internationally, especially since major parts of the protocols were based on standards that were generated out of Europe.
So, over the last year we have done that, and we are about to go to a final ballot on three or four of those standards where we take European standards and, through ISO TC 215, working with IEEE, have partitioned those into some of the specific standards that I mentioned in the previous testimony that I submitted.
What I am saying, I think, in my testimony is that -- the other part is, at this point we really don't have any good alternatives, in terms of other medical device standards for these classes of devices.
The need for standardization within that marketplace to be able to enable the kinds of systems we are talking about is very clear. I don't think that is being argued today.
As far as I know, there are no other standards activities out there, that is anywhere near providing that same -- filling those same kinds of requirements.
Companies, major companies, like I said Biosys, are now going to market with product, because they are finally seeing something that is implementation as a full stat.
That is a long-winded response, but hopefully provides the kind of background information that you need.
DR. COHN: Any more questions on this issue? Okay, thank you.
MR. COOPER: I think that, while you were out, one of the things I might just reiterate is the harmonization effort that we are doing with the LAPOCTSIG.
This is the question that was discussed a little bit earlier about trying to pull all those things together.
What I indicated was that, as a result of this strategic study that was done in Europe, the best activities to identify messaging scenarios where you need to have communication going between both environments, identify out of that what are the mappings in terms of the model and in terms of the nomenclature, and then just go and standardize those mappings, as opposed to trying to go across the board, and make matches for everything.
DR. MC DONALD: That makes sense. IEEE meets coincidentally with HL7, so I am sort of familiar with some of that.
DR. COHN: Why don't we move on. David and Lloyd?
MR. CLUNIE: We are also doing a tag team effort. I am David Clunie. I am a neuroradiologist from Princeton Radiology and Pharmaceutical Research, and I am co-chairman of the DICOM committee.
Lloyd Hildebrand, with me, is an ophthalmologist and he is the other co-chairman of the committee.
To address the questions asked us, do you plan to apply for ANSI accreditation and, if so, when, the short answer is no. The more elaborate answer is, why no.
We are an international organization and the majority of our participants are not from the United States.
We have multinational vendors. We have users from different countries. We have professional societies from different countries.
We struggle to avoid being perceived as a U.S.-based standard, in order to gain acceptance in the user community end market in Asia and in Europe.
To avoid that issue, we have a policy of not seeking national member body accreditation. Otherwise, if we did it with ANSI, we would have to do it with DIN and BSI and Standards Australia and so on and so forth. So, that is our policy.
NEMA, who are our primary secretariat, are U.S. based. They are in Washington. NEMA itself is an ANSI-accredited standards development organization.
In order to achieve credibility in the world of official standards, if you want to call it that, our approach is to seek approval of DICOM as an ISO standard.
To that end, we are working with TC 215 in ISO in order to achieve that, and use a similar process to that used by the IEEE, which we refer to loosely as the pilot process, and what HL7 is also using as a means to gain ISO adoption of DICOM. So, that is the answer to that question.
What version of DICOM is considered to be current? I guess versioning has been a major topic of conversation this morning. It is something that we have struggled with from the beginning.
There is only one version of DICOM and that is version 3.0. They are giggling in the background and I will elaborate on that short answer also.
It is called 3.0, and we have actually dropped the acronym 3.0 in our official communications now. We just call it DICOM.
The 3.0 came from the fact that it was the third effort. Much as IEEE 1073 have tried several iterations of this, the original ACR NEMA standards were a miserable failure, to put it bluntly, and DICOM itself was the third attempt and that is why it is called DICOM version 3.0. It was produced in 1993 and it has been DICOM ever since.
Like with NCPDP, we continually add functionality and features. So, as we add features, we add them in what we call a supplement to the standard.
It happens that those supplements are then folded into the text of the standard and reprinted on an annual basis.
At any particular point in time, the standard itself officially constitutes the last printed edition, including any supplements since then. That doesn't mean that it is a version of the standard.
In your letter, for example, it is probably inappropriate to refer to DICOM 3.0-2000. There is really no such thing. There is just DICOM.
Now, to make it manageable from an implementation and performance perspective, though, DICOM is a very extensive standard that has many applications and many different components.
A CT scanner that was made in 1993 and implemented the CT relevant services from DICOM in 1993, still works with a scanner made in 1994 or 1995 or 2000 or 2001, and will continue to work ad infinitum, as far as DICOM is concerned.
The additional functionality that is added does not impair or, in most cases, replace any preexisting functionality that is implemented.
We also have a maintenance process that involves corrections. Those are usually clarifications. Occasionally, we will actually nail down an area of ambiguity that breaks existing implementations, but our line is that those implementations were fluid and the other implementations that interpreted the ambiguity correctly are now the correct ones.
That is how versioning applies in the case of DICOM. It is a somewhat long-winded explanation, but there is only one DICOM.
Each year, it gets more extensive in its coverage, but devices that comply with DICOM last year will work with next year's devices without any problem.
So, our recommendation, with respect to the reference in the letter, would just be to refer to DICOM unqualified, or DICOM 3.0, if you must, but definitely not to include the year.
DR. COHN: I am sorry, maybe just to clarify, it is updated yearly?
MR. GUINAN: Oh, yes. The printed edition is updated yearly. As I say, the official version of the standard at any instant in time is the printed version last available, plus any supplements that are available on the web server as final text.
So, for example, DICOM 2001, which we submitted to the printers I think a month ago, in January there will probably be three, maybe four, supplements that extend that printed version.
They are addressing certain new features, attribute level, confidentiality for security, de-identification is supplement 50-something or other. When it goes to final text and becomes available, it will be part of the DICOM standard, even though it wasn't in the printed 2001 standard.
The other interesting thing is that we are moving away from dependence on the printed standard as the official standard, and NEMA is talking about -- I am not sure if it was publicly announced -- that policy will change, such that our standard will be available free, in its final form, on the web.
So, it may, in fact, be updated on a more regular basis, but that has not yet been passed by the NEMA board of governors.
DR. ZUBELDIA: You never make mistakes? You never have to go back and correct the previously printed supplement?
MR. GUINAN: Oh, all the time. That is what the maintenance process is for. That is what correction proposals are for, correction items, and we are -- where we have made design errors, we live with those.
For example, if someone says, we would rather you did your query a different way, that is fine, but that is a design decision. We stick with our design decision, unless nobody implements them, in which case we retire that component to the standard and come up with a new and better way.
Once we have implementations in the field, we live with our mistakes. We add new features, but our number one goal in DICOM is interoperability.
Now, we haven't achieved plug and play to the extent that Microsoft and Intel may claim that they have achieved plug and play. I won't debate that.
Our goal is that you can plug in one vendor's CT scanner to another vendor's actual work station. In terms of transferring information, they should operate seamlessly.
Application level functionality we don't try to standardize, obviously, because that is where added value is in the marketplace, and that is where competition comes from.
In terms of transferring objects and information, our goal is to strive for plug and play. Once we have made a decision on how to transfer a CT object, unless there is a radical change in CT or MR technology. That is something I will come to a bit later on. We don't go back on those decisions. Yes, of course, we do make mistakes.
I think that probably addresses the third question also, which is when will the next version of DICOM be available.
On the one hand, there is no next version. On the other hand, we print it every year, so about the third quarter of 2002 would be another alternative, if you wanted that.
I still recommend that we don't mention version in the letter, if that is at all possible.
Please describe the interoperability and data comparability issues being addressed at the DICOM HL7 working group.
Our focus is very like what Todd was mentioning. Where we have particular problems to deal with, where we are living in a world where you have the imaging world which coexists with the information world, say the HL7 world, for argument's sake, there has to be communication under certain circumstances, such as provision of patient demographics to the scanning device, such as transfer of measurements made on a work station back to the reporting world, which often lives on the information system side.
When scenarios arise that need to be addressed in a joint manner, we work together to try to harmonize our information models.
Our focus is on making sure that the RIM, and that any explicit information that 2.X versions of HL7 have, are consistent with our way of doing it.
When DICOM was first written, the HL7 folks, the people who work on both HL7 and DICOM, acted to make sure that we didn't do things too differently from HL7.
There are imaging department-specific issues that need to be addressed, and pragmatic decisions are made but, by and large, we have a very similar information model.
In the real world of implementations, the order has come from the HL7 side. So, the identification of patients and transactions tend to be well matched in the DICOM world.
The DICOM standards have become more sophisticated in terms of its information model, to match what happens in the real world of information systems and the HL7 side.
That is our primary focus in the joint working group. There is also work on achieving consistency in terms of how we deal with reporting.
HL7 has an initiative in terms of doing reports that are more than just plain text in OBX segments. DICOM has an initiative in that respect.
We are very image focused and HL7 is very generic document focused. We are trying to achieve harmonization there, so that, whatever we come up with on either side, there will be a bidirectional interoperability in terms of mapping both the data elements and the information model at that level. So, that is a very major focus of the work that is done jointly in that group.
The other area where we have done a little work is on the SECOW standard, which I guess is part of HL7.
I notice it is not discussed in the context of this group, which struck me as rather odd, seeing as how SECOW is a potentially vital part of patient medical records.
We have also done a little work in SECOW, because SECOW, as a means of sharing context on the desk top, also needs to share context about images.
We have pushed in our DICOM identifiers into a SECOW version, whatever the next version is that is coming, so that you can share context about specific DICOM objects that come from the DICOM world, yet are driven by an application that is working in the HL7 and SECOW world.
What new capabilities are expected in the next version of DICOM? Sorry, I skipped a question. Sorry, I am back to question four now.
There is quite a range of things that we are working on actively and expect to be mature by the end of 2002 or possibly 2003.
First, we are trying to make it easier for people to configure their systems. As imaging systems and fax systems become much larger, deploying the individual nodes becomes difficult.
We would like to ge to a point where it is as easy as plugging the lap top in at work or at home, and DHCP takes care of your IP addresses, your DNS servers or that kind of low level detail.
We are adding network configuration services, which leverage off such existing internet service such as DHCP and DNS, in order to automatically configure DICOM devices as they are installed.
This is to address a common perception in the user community that it is difficult to install DICOM devices, and it is. That is a fact.
Now, we are also recognizing that there has been a change in MR and CT technology. For those of you who are familiar in the imaging world, in the old days we used to look at three or four sheets of film per patient.
With the new multi-slice high speed detectors that scan from the head to the toe in about 20 to 30 seconds, we are dealing with what might come out to 50 or 60 or 100 sheets of film.
The volumes of data are becoming enormous. Also, we are getting into the world of real time CT, real time MR, where you actually interact with the patient and image cross sectionally live, sticking in needles, catheters and stuff.
That requires a different approach to encoding the image objects. So, there is an initiative underway to have new MR and CT information objects that cope better with the much better volume of data and address new kinds of technology such as profusion, diffusion imaging, spectroscopy and so on and so forth.
The new MR objects should be finished by the end of next year, the new CT object by the end of next year.
We are also encoding computer-assisted detection and diagnosis objects. We have finished the mammography CAD object, which is now part of the standard, and has been implemented by several vendors and we are working on the chest computer-assisted diagnosis object to encode the results of automated detection of lung nodules and interstitial disease, so that they can be transferred to another vendor's work station for display, or passed around in the packs, that kind of stuff. That is a big initiative that year.
We are constantly working on codes. Codes are one of our biggest nightmares. In the imaging world, we get codes from a lot of other places. Most are site specific.
There is no good clinical procedure coding system in the world that we have been able to find that people use extensively.
CPT codes are oriented toward billing and reimbursement, not ordering and performance of a clinical task.
We are loathe to develop our own, because we are too small and too image focused to worry about that. So, we are constantly looking for good sources of codes that don't require royalties to use them.
So, we sometimes develop them and sometimes seek them. Lloyd, I don't know if you have any other comments to address on that score.
The other thing is, we are adding more security features. To skip to the last question, we already have in DICOM transport layer security. So, we use, for example, SSL as a security mechanism.
In an e commerce situation, you use your web browser. You talk to Amazon, for argument's sake, with SSL, securing the transaction. We do the same thing with DICOM.
We have security in media, leveraging off similar internet standards, the PKCS family of standards, for media security.
We also have an electronic signature capability that we just finished off toward the latter part of last year, that allows us to digitally sign selected sets of attributes inside an image object, or forward object or away-form object, and to apply multiple signatures if necessary and so on, using a cryptographic mechanism, again, using standard RSA-type technology, SHA-1 and so on.
We are working on attribute level confidentiality with a focus on the de-identification requirements of HIPAA.
We accept that there are many non-clinical scenarios such as teaching, remote service, clinical trials, where you need to maintain the original identifying information for the purposes of contributing to the audit trail or for authorized personnel, but it has to be de-identified for the purposes of the trial personnel or the service personnel.
So, we are adding the ability to replace and encrypt the original attributes in an object in DICOM.
There is also an initiative to harmonize our audit trail strategy with other groups like HL7, to use freely-available internet technologies, secure syslog, that kind of thing, to maintain a central audit trail mechanism, but contribute to it from disparate types of systems, be they in the HL7 world or the DICOM world, or some other standards world.
I think the other two questions, with respect to the query retrieve mechanism, DICOM's query retrieve mechanism is based on the DICOM protocol.
We have a very strict conformance mechanism. Although an individual vendor might make their data base interface available to the user, to, say, performance sequence query in the normal manner that one might query any data base, that doesn't fit well into the paradigm of using DICOM in a conformed environment, guaranteeing that one device will work against another.
We have a very simple query model, that we know one work station will work with another scanner or another PAX, where the DICOM query, implemented using the DICOM protocol and DICOM messaging and DICOM information model allow you to query by patient study series image.
It is relatively simple. It is just a way of asking for, or searching for the particular studies that you want, to look at the images thereof, which is why we have what is called a proprietary query retrieve mechanism.
We just see it as a fundamental part of our standards that is widely adopted and widely utilized. It doesn't stop anybody performing a sequel query if the system happens to be implemented as a data base that supports that, but there are many that are implemented using non-sequel data bases, and we see that as the vendors role, to decide how they want to build their product inside. So, there are no plans at the moment to add a sequel mechanism to it.
Finally, should NCVHS recognize DICOM as an informational model in structure, or as a communications protocol, I think the success of DICOM is predicated on interoperability, which in turn is predicated on conformance which, in turn, is predicated on accepting the whole path through the layers of the iso-communication model, which includes the communications protocol, the encoding mechanism, the messaging system, as well as the data dictionary, the information model, and the service classes that are layered on top of all of that.
So, DICOM is kind of an all or none thing. Either you buy into the approach or you don't. So, DICOM doesn't have the ability to separate the information model and the data structure from the communication protocol.
The exception to that is the ability of that to encode a DICOM data set into an offline file, which is interchanged in interchange media.
Again, we have very strict requirements in terms of how that is encoded, compression mechanism, transverse syntaxes that are used, how they are grouped, the presence of a DICOM directory on the media, the type of media used, be it CD or MOD or whatever.
Again, that is grouped into an entity we call a media application profile and, again, is a conformance mechanism that dictates how that needs to be implemented and described.
MR. COOPER: I will just reserve a few quick comments from the user perspective. Bringing these things to life in the user environment is really what my focus has been within DICOM.
DICOM evolved out of the radiology world, but we have seen a tremendous expansion of that into all clinical specialties and biomedical imaging systems.
Ophthalmology has certainly been very active in that since 1996 when the DICOM standards committee opened to beyond radiology.
We have also seen the evolution of supplements to the standard which support our clinical entities.
The adoption, however, of these standards into the clinical practice, so that they become very pragmatically deployed and also usable by the end user as the physicians and ultimately impacting patients, is a lot slower process.
Part of that is a chicken and egg problem. How can vendors supply something that isn't being demanded. How can somebody demand something that isn't being supplied, without understanding what it is.
There is an educational process that has to occur. Certainly, within our specialty, we have seen that. In the last three years, we have had DICOM demonstrations within ophthalmology at the annual meeting.
We are now seeing DICOM conformance statements being adopted by a significant number of vendors within the ophthalmic space, which is a different group of vendors, in large part, from the radiology space.
I think what we are seeing, we are seeing some second generation specialty groups that are now starting to adopt it, and we are starting to see that cycle of adoption of the technology, which I think is ultimately the important part of why we are doing this.
DR. COHN: I have a question that is actually to you, Lloyd. Thank you for your comments beyond radiology, which is nice to be reminded about. Have you see the draft document that we are referencing here?
MR. CLUNIE: Yes.
DR. COHN: Is our terminology, where it states supports, a table of information for imaging devices/equipment to diagnostic and review work stations and to short and long-term storage systems, is that the right way to describe it?
Do we need to in some way describe DICOM differently? Does this cover, David, your view and, Lloyd, your view of what we are describing?
MR. CLUNIE: Actually, I think it is a very good description. It deftly avoids some of the controversial areas of turf overlap with other standards, by referring to and from imaging devices without mentioning images, for example.
Actually, it is a very impressive statement that we will re-use, if you don't mind, in some other contexts.
I think there are many other features of DICOM that are directed toward, for example, work flow enhancement. There are work list features and so on and so forth.
There is radiotherapy support and other things like that, but they get into too low level detail to be captured in such a broad paragraph. I think this is quite good.
MR. COOPER: I would agree. Just the fact of just transmitting an image sometimes isn't all that useful. Knowing who the image is of, the patient information, the demographic data that goes with it, the image acquisition context that goes along with it, those information elements are important. I think the more generic expression of that is important.
DR. COHN: Okay, thank you. Questions? Comments?
DR. ZUBELDIA: One question. I would like to get a better understanding on the DICOM standard and the imaging compatibility.
We have testimony here before, like each vendor has an imaging standard to that one vendor that works well with a viewer, that is provided by that same vendor.
They don't necessarily have interoperability among themselves. Is that the case?
MR. CLUNIE: Actually, you would be surprised. In the old days, that was definitely true. You would take a particular vendor. I used to work for GE, so I will pick on GE, for example.
We would build systems that did it the way we needed it to meet the customer's requirements. So, it would have certain features in the CT scanner, for argument's sake, and you would need them conveyed to a work station.
So, you would figure out a protocol in an ad hoc manner to transfer the information you need to do, let's say, a 3D reconstruction, for which you need to know the order of the slices and their thickness.
Then, the DICOM standard came along, as an industry, from both the vendor and the user side, in order to try to allow interoperability from the 3D work station from, say, Siemans or Philips or Picker, with a GE acquisition system.
Users didn't want to be tied to one particular vendor. This is the genesis of any standard like this, I suppose.
What was defined was a way of communicating which involves the messaging, the transport layer, all the lower levels of the ISO stuff. We use TCPIP, just pragmatically, because it works.
Then we had to have a common information model. So, we had to describe the patient's name in the same way, the study identifiers in the same way.
We had to include the pixel data for each slice the same way, and we also have to have technique-specific information, specific to, say, CT, like slice thickness and patient orientation and position, whereas in an ultrasound you don't have a slide thickness per se. We have modality specific characteristics like that.
To that end, we have achieved tremendous interoperability. You can take an image from any vendor scanner and view it on any other vendor's CT work station.
You can view it, you can do a 3-D reconstruction and all that basic kind of functionality is essentially seamlessly interoperable.
Indeed, the vendors, in order not to have to implement translators, which are tough, are now building systems that are native DICOM inside, so their data bases store DICOM objects, as their native protocol communicating between their own work station and their own CT scanner uses DICOM. They don't have a proprietary protocol any more.
Indeed, it is getting harder and harder to get systems from the vendors that even talk to your older equipment that did use a proprietary protocol, even from the same vendor, which is interesting.
Where there is discrepancy is at higher level functionality. If a vendor comes up with a very sophisticated, dynamic kind of application that involves encoding of information that is specific to their acquisition technique and specific to their imaging processing technique, that gets carried in all the private fields, which another vendor may not be able to utilize.
So, the level of functionality beyond basic viewing and 3D functionality and measurement capabilities may be added value that the vendor will provide in private fields.
Now, what happens to those over time is that the users say, well, now I want that feature on your competitor's work station, or on a third party's work station.
So, either they exchange private information and come to a mutual understanding, or they push the standards committee to add more capability to the DICOM standard itself.
That is what is happening with the new CT and MR objects, which are almost an order of magnitude increase in sophistication, carrying new parameters that were never even conceived of, because the physics hadn't been invented in 1993 and prior.
Again, things like diffusion and profusion imaging, many of the real time techniques, many of the cardiac techniques for MR, they just didn't exist in those days. That is why the standard progresses, and we reach a new level of interoperability.
The vendors will always push it to a limit above that, because that is where their competitive advantage comes from. Does that actually answer your question?
MR. ZUBELDIA: Yes.
MR. COOPER: From the user perspective as well, I think sometimes, this is a feature that, you see a feature on one device and you want the feature on the other device, and you expect that to be the issue of interoperability.
What we are doing in ophthalmology, we are trying to also leverage the clout of the professional society to try and help ensure that level of interoperability is there from the very beginning.
Having had the history of DICOM for many years in radiology, we can look back at that and say, how can we avoid those problems. How can we use a professional society to help the vendors collaborate on this and build interoperable tools for the users.
That is really what we use a lot of our demonstrations at the annual meeting for, is to start to get the vendors to work together, and get the users help them define this level of interoperability.
MR. CLUNIE: Actually, if I may briefly elaborate a little on the scope of DICOM in terms of specialties, it was most successful in radiology, no question. In cardiology, it became an overnight success and is now probably even more successful than it was in radiology in some respects.
In addition, in ophthalmology, as a set of visible light applications, we also have the capabilities to support sliding gross microscopy pathology, gastrointestinal endoscopy and other forms of endoscopy, external photography, dental applications. It is increasingly used in dentistry, which is very reassuring.
The biggest issue is actually we have, to some extent, become a solution in search of a problem. In the radiology world, our business is providing images to referring physicians. They want to see the images.
In the other world, the images are part of the deal, but they are not the primary focus. It is more the report.
The pathic report is more important than the picture of what you see down the microscopes. Most physicians are not very specialized.
So, we have a mechanism of distributing information that are images about other specialties, but the question is, why do you need them at the other end.
We are really driven by being pulled by the needs of the referring physicians and others, in terms of which specialty do we grow into.
There is a need for imaging. We have tried to support any specialty that approaches us to deal with it.
DR. FITZMAURICE: I want to preface this by saying that I am not a physician. So, some of my questions may sound a little bit silly, I hope not insulting.
It seems to me that there is a lot of technical ability here. It is kind of equivalent to faxing a cartoon from, say, Jeff's machine to my machine and I look at it, and it doesn't have a caption. I can think of an image being transferred.
A physician, when he makes a patient referral, says maybe, I want to know if this bone is broken. I want to know if there is a tumor on the left side of the lung, or I want to know if there is anything abnormal.
So, he asks a query and he gets back the response, yes, there is, no, it is not broken, but it may be this. You get an interpretation back.
Is that also part of DICOM, setting up the codes for making a query, asking a question about the image, and getting a response back? Is that something that would be more in the domain of something like LOINC, to get a professional query and response?
MR. CLUNIE: That is a very complex question, because it touches on a number of different areas. First of all, the work force scenario in a radiology department is that images are made by technologies, by and large, with radiologists' assistance as necessary, and then they are interpreted.
It is a cyclic process, where images come to your desk and you read them. You dictate a report, voice recognition takes care of it. You point to things maybe in a more sophisticated system and a report is generated.
That report is then transmitted with the images in a paper or in an alternate fashion, to the person who requested access.
It becomes part of the medical record. So, anyone subsequently who needs information, looks at the report.
Now, in the real world, in the electronic world, where do those reports actually live? They are generated in the radiology department, but they live in the IS world. It is generally the HIS world, or the fax machine, to be blunt about it, that exchanges these things around an enterprise that spreads beyond the walls of the hospital.
Now, when in a hospital, you certainly consult the HIS usually, or sometimes the RS, but usually the HIS, to review the reports on that particular patient.
If you are looking at a film in a view box and you say, is this abnormal, it will generally be accompanied by the report that the nurse fetched for you that says, yes, it is, no, it is not. It is our job to turn that around in a timely fashion.
In most practical HIS systems, the queries are really at the level of the encounter, or the visit or the examination, if you want.
When you pull up the information about the patients on a particular date, then the report is accessible to you.
You don't generally, in the work flow, make such ad hoc queries as you are describing, like, does a patient have a broken bone. That is not the kind of query you might make.
More pertinent, you might make a query, give me a list of all the patients with broken bones over the last three weeks, either for management purposes or for research purposes or for teaching purposes. That is where these codes become so vital.
The way we have tried to address that in DICOM is to take the same codes that are used by the rest of the world -- for example, let's say SNOMED codes for argument's sake, or other codes.
LOINC codes are used more widely in ultrasound, for example. Then, use those in our reports in a structured manner.
We have a feature in DICOM that we have struggled with for many years. It took a lot of convincing to add, that is now part of the standard, called DICOM structured report.
It is a way of conveying a high tree of information that can be text or codes or measurements or pointers to images, or coordinates on images, pointers to wave forms, coordinates of wave forms that were acquired synchronously with the image data.
That becomes a report, either generated by machine, for example, a pressure wave form that may be acquired in conjunction with a cardiac cath study, makes automated measurements.
That may be entered by a human being. It may be part of the work on their reporting work station. Then we have to send it somewhere.
We realize that our world of imagine is relatively modest, but this is where the difficulty arises. This is why we struggle so much in the joint working groups to try to harmonize with HL7, so we can push our structure data across the boundary to HL7, with the shared information model, shared means of encoding codes and text, so that they can then code it to their new clinical document architecture, for argument's sake, and transmit it around their system.
The worst case scenario, we flatten it into plain text and send it in a traditional HL7 version to some message. That is how we address that issue.
In terms of making the kind of ad hoc queries you are describing, certainly, were such queries to be required, and were such reports to be encoded using such a mechanism, a system as you propose could be constructed.
Whether there is a need for it or not is another matter, and we are not getting such demands, and we don't build such systems at the moment.
DR. FITZMAURICE: Let me see if I understand it. If I were a doctor, which I am not, and I am looking at an arm which may be broken, I send the patient to the radiology department and they send a query to the radiology, and then I get back an answer to that question?
MR. CLUNIE: They are one and the same. We don't do images for fun. We get paid for it. We do them because we are asked to do them.
We are really being asked to answer a question. Does this patient have a stroke. Does this patient have a broken forearm.
That may be accompanied by a specific request, that is, x-ray the forearm, but how we do it is our problem.
How we image the patient to do, for example, an MR of the brain to look for a stroke, or a CT of the brain to look for a stroke, depending on the phase, for reimbursement reasons and for regulatory reasons, the request for the specific procedure has to come from a referring physician.
That is, in many ways, unfortunate because, really, the radiologist is in the best position to decide what is the most appropriate study.
The request for the imaging exam is implicitly a request for a report. When the images go back, they are accompanied by the report.
DR. FITZMAURICE: So, that is outside the domain of DICOM, to determine the syntax and the context of the request, and then the form in which the report comes back.
MR. CLUNIE: The requests come in HL7.
DR. MC DONALD: You made it more complicated than it is. You send the patient to the radiologist. They tell you. There is no query. They tell you if he has got a broken arm or not.
DR. FITZMAURICE: Is there a code for the broken arm coming back, or do they have to write that in free text?
DR. MC DONALD: That is an interesting issue. That is another story. The one to one dialogue, it is between physician to physician through a piece of paper. There is no high technology involved.
MR. COOPER: From a clinical perspective, an imaging study is done and the report comes back with the imaging study. So, those two objects are kind of linked together. So, the report does come back.
When it comes back, there is a structure within DICOM that can use a code, if there is a code available, or can use free text.
So, in structured reporting, that object within structured reporting is highly flexible. Clearly, the more codified we can build that system, the better off we are.
DICOM is structured in such a way that we can use external codes to be mapped into the regions of interest in an image.
DR. FITZMAURICE: Whose job is it to develop those external codes that describe, yes, the patient has a broken arm, and here is where it is.
MR. CLUNIE: That is a very pertinent question. What we are trying to do is find someone who has defined those and say, these are the code sets we prefer you to use with DICOM.
There are many organizations that have worked hard to define definitions for procedures, definitions for anatomical locations, definitions for particular findings, as explicit as left ventricular diastolic dimension, for argument's sake, or as generic as, it is broken.
When it is broken and it is tied with arm, they are mixed together. How you mix and match becomes an issue.
We at DICOM always encode in band, or with the code, that protects meaning as well. That is mandatory in DICOM.
When we say, you know, T-04000 as in SNOMED version 3.0, nobody knows what that means. So, we send the word breast as well, because that is the code for the anatomic region, breast. Even if you don't have the code sets, you can still understand the report.
DR. COHN: Maybe I should just make a comment here, as one who deals frequently with fractured arms. I am reminded that a picture is oft times worth 1,000 words, maybe even 1,000 codes.
I think DICOM obviously offers us a tremendous ability to at least look at the images, transfer and save the images. Last question or comment?
DR. MC DONALD: This is a question that I think is not a standards question. It is maybe a policy question, but it is an interesting observation, that radiology almost never returns a code of any kind, and other imagers do.
There are ICD-9 codes that would do just fine for these retrieval purposes. The code you get back from a radiology bill-coded text, is the referring physician's question code, you know, is this a fracture. That is a policy issue.
MR. CLUNIE: I would like to just address that. ICD-9 codes may be fine in that situation, but certainly in ophthalmology they are very inadequate to represent the different levels of pathology and imaging that we use.
As a result, in ophthalmology, we have actually taken upon a sub-project that Dr. Cohn is certainly familiar with, the convergent medical terminology project.
We have actually developed a subset of that, in which we are taking ophthalmic terminology now and fully modeling out terminology, so that we have a set of codes that we can use for that.
DR. COHN: Actually, I wasn't arguing that ICD-9 could handle radiology very well either, but it would go a lot further than no codes.
MR. CLUNIE: I agree with that.
MR. COOPER: There is a kind of a paradigm shift in the way in which radiology reporting is practiced and needs to take place.
The only reason radiologists put in any code at all right now is to be reimbursed. If the code that was sent in a request is adequate and sufficient for that purpose, then they are happy to use that.
It is only the academic institutions that are well motivated to code well. I think that somehow we have to motivate the radiologists to do better.
There are only a limited number of options for motivating radiologists, and I am not quite sure how to solve the problem.
DR. COHN: I might also add that I think there is an ongoing debate in the radiology community also, which has to do with whether or not radiologists actually make diagnoses or whether they describe findings.
With that, if it is okay, why don't we take a break. It is about 12:35, I believe, right now. Why don't we take 45 minutes.
I obviously want to thank our testifiers for really a wonderful set of testimony. They have really helped us, I think, move forward with this, and we want to thank you all.
[Whereupon, at 12:35 p.m., the meeting was recessed, to reconvene at 1:20 p.m., that same day.]
DR. COHN: I think, Dr. Yasnoff, you are at the top of the agenda this afternoon.
DR. YASNOFF: Let me get started. I am presenting to you today the national agenda for public health informatics that was developed at the American Medical Informatics Association spring meeting.
The one thing that I do want to make clear is that I am not representing the CDC or even the government in providing this information but, rather, summarizing the consensus of the folks who were at the meeting.
This meeting was held in May in Atlanta. There were over 500 people there from public health and from informatics.
There were six breakout tracks and I will be talking all about those. Frameworks for recommendations for each breakout track were developed prior to the meeting
Each breakout track had four one-hour sessions, so there were 24 hours of breakouts altogether, and then there were plenary presentations from each track.
As I mentioned, the recommendations represent the views of the attendees.
The first area was in the area of funding and governance. In particular, in funding, the recommendations were that information management should be part of the core public health budget, and that the vision for information should be funded, not information technology, particularly not information technology for its own sake.
Diverse funding sources are needed, and funding has to be adequate throughout the life cycle, planning, start up, planning, implementation and maintenance.
In particular, dedicated funding is needed. As I am sure you are aware, in public health there are dedicated funding streams, typically disease oriented.
There is no dedicated funding stream for information technology in public health, or for information systems.
In the area of governance and planning, leadership is clearly needed, and we need to create planning and management structures that include all stakeholders, assure that public health and information technology are both represented in broader systems planning, and it was recommended that we develop a merged superset of public health and informatics planning models, that it was found at the meeting that those planning models have a lot in common.
Finally, the third area of funding and governance, the business case area, it was recommended that a business case needs to be established for continuing investment in information systems.
Actually, I think over time you will see more and more evidence in that regard. Also, there needs to be a business case for public health information architecture.
The second of the six areas was architecture and infrastructure. In the area of infrastructure, we need dedicated internet access, work stations and training for all public health personnel and health care providers, and public health officials need software, tools, training and methods for access to data.
In the area of architecture, we need to develop an implementation plan for the public health information architecture.
I should point out that I have presented these recommendations to the NHII work group of NCVHS. Obviously, this one is more directed to them.
We also need to develop a public health data repository with person-based integrated data, and establish a process to develop an architectural model for the public health data repository.
With respect to architecture policy, we need to establish procedures for monitoring compliance with audited evaluation criteria in public health data systems, implement access control measures and, in particular, computational disclosure control, to make sure that we are not inadvertently identifying folks with data we are distributing, when we don't intend to.
It was also recommended -- this was a controversial recommendation at the meeting -- that we consider establishing a unique personal identifier to facilitate integration of data from multiple sources.
Finally, the last sub-area of architecture and infrastructure, interfacing public health and medical care. We need effective communication and work flow management capability between public health and health care, and I think that relates to what we are doing here.
Also, we need to minimize the impact of public health data collection on health care providers, by tapping into existing data streams.
The third of the six areas, which I will spend a little bit more time on, is the area of standards, because obviously it applies to what we do here.
The first sub-area, development and implementation, we need to increase awareness of, and participation in, current standards development activities in the public health work force, particularly building on the work of the Public Health Data Standards Consortium.
We need to develop and maintain a web accessible list of existing standards and standards development groups and activities relative to public health. This is something that our group may want to discuss.
It was interesting at the meeting that many folks understood the importance of standards, but very few were really familiar with the range of existing activities. So, you can have the situation where well intentioned folks in public health want to adhere to standards, but are not aware of where to look to find the standards they need to adhere to, and we need to take care of that problem.
We need to identify gaps in existing standards and communicate these needs to SDOs. In particular, there are a number of areas in public health where I think there are gaps in existing standards.
We need to promote consistent use of standards by the government, including HHS and EPA, and obviously we are working here to do that.
The second sub-area of standards development enhancement, we need to increase use of CDC's public health conceptual data model and modify and expand it based on user feedback.
Additional standard messages for public health reporting are being developed, and I think we will hear more about that tomorrow in another presentation from CDC.
We need to establish a mechanism for ongoing maintenance and expansion of public Dwyer tables. The Dwyer tables use standardized codes, mostly LOINC but sometimes SNOMED, to identify tests and specific results of those tests that should trigger electronic lab reporting to public health agencies. We have heard here before a little bit about electronic lab reporting.
We also need model state regulations to promote more consistent reportable disease requirements across the United States, and I want to be very clear about this.
This recommendation is not that the same list of diseases should be reportable all across the United States. That was not what was recommended.
The recommendation was that if disease X is reportable in one location and in another location, the data elements and format for that reporting should be identical.
We also need specific implementation guidelines for creating and transmitting electronic lab reporting messages, using standards, and we need to look at mechanisms for promoting and enforcing their use.
We need continued use to harmonize guideline formats within HL7, arden syntax, gliph and others, and assess their ability to represent population and preventive health guidelines.
Finally, in the standards area, we need to create fully specified data base versions of ICD-9-CM and ICD-10-CM, to facilitate the development of automated mapping from detailed clinical terminologies to ICD codes, for statistical reporting and billing purposes.
Moving to the next area, research, evaluation and best practices, in the area of best practices, there is need for agreeing on a process for developing and disseminating best practices, establishing standards for performance at all levels, developing the repository of best practices, presumably a web repository, with mechanisms for discussion, identification of consensus and endorsement.
A program is needed to fund demonstration projects showing best practices in privacy protection.
In evaluation, it was felt that evaluation should be explicitly tied to Healthy People 2010. Outcome measures needed to be standardized and include data quality, economics, transferability, and existing programs should be evaluated first.
In the area of research, there was quite a bit of discussion. There was a consensus that we needed a research agenda for public health informatics, that existing informatics knowledge, techniques and methods should be used in public health informatics research, with the obvious implication that they are not always used.
Multidisciplinary teams need to be involved in public health informatics research. An informatics component should be included in every public health research project proposal and report.
Additional and not re-allocated research funds should be provided for public health informatics. It was also recommended that a lead research agency for privacy, confidentiality and security be established.
That moves us to the area of privacy, confidentiality and security. First, in the area of privacy and confidentiality monitoring, it was recommended that there be a national forum on privacy policy, something like the national privacy advisory commission, analogous to the national bioethics advisory commission.
It was recommended that there be an exchange across information systems. For example, the cross-jurisdictional exchange of immunization data.
All public health data systems should be required to have a stated purpose, privacy board, confidentiality agreements. In other words, they should follow fair information practices, and model security policies are needed.
Finally, in the area of security, it was recommended that HIPAA security requirements be adopted as public health security requirements.
Also, security preparedness at all levels of the public health system should be reviewed, specifically addressing denial of service attacks.
Let me say a word about that. It is clear, especially after recent events, that in a public health emergency, normal interest in public health information can easily result in the natural of occurrence of what mimics a denial of service attack on public health sites.
Therefore, those sites need to be prepared for this, and be ready to ensure alternate methods of communication to carry on the business of the agency.
Finally, in the area of security, it was recommended that indirect funding options be considered for security, since these investments represent infrastructure that benefits all programs.
Finally, the last area was training and work force. Educational programs establish new, and strengthen existing academic programs in public health informatics.
Develop a national competency based continuing education program. Enhance the CDC public health public health informatics fellowship program.
In curriculum, it was felt that instructional guidelines for public health informatics were needed for both the current work force and in accredited schools and programs in public health.
There also needs to be a comprehensive and consistent curriculum about data security, privacy and confidentiality.
It was felt that the public health work force needs a basic level of knowledge about these issues, so that they can understand why they are being asked to do certain things, to protect privacy and confidentiality.
Consideration should be given to establishing an ethical, legal, social issues program in public health informatics.
Appropriate public health groups should be involved when developing public health informatics curricula. With informatics, a career track for public health informatics should be developed.
With respect to meetings and organizations, folks obviously enjoyed this meeting, because they recommended that the opportunities for public health and informatics folks to come together should be expanded.
They also felt that AMIA's prevention and public health special interest group should be strengthened and that NLM, working with AMIA and CDC, should sponsor meetings for public health and informatics outreach throughout the United States, and that is actually being done.
Finally, in the sub-area of competencies, there is clearly some level of dissatisfaction with current definitions of public health informatics, because it was recommended that it be defined.
It was also recommended that CDC, in other efforts to develop core competencies in public health informatics, be supported, and those efforts actually are ongoing.
Informatics competencies in other health-related fields should be examined. Also, it was suggested that the AAMC medical school informatics objectives be applied to public health informatics.
I believe there are a total of 74 recommendations. It is a lot of recommendations. One of the things that was not done at the meeting, that perhaps should have been done, is to limit the number of recommendations.
Let me say a word about the themes that go through these recommendations, at least as I see them. There are basically two overall themes.
First if coherent governance of public health informatics activities. This is really a big need. All stakeholders need to be included.
Standards need to be established and consistently used. Confidentiality policy needs to be developed and monitored.
We need to identify and disseminate best practices and promote improvement through research.
This is a difficult problem, because there is no existing place you can point to that really have responsibility for governance of public health informatics activities.
The second major theme related to public health informatics training, it is clear that basic skills are needed for the entire public health work force, and more advanced skills are needed for decision makers.
In terms of next steps -- and most of these have already been done -- these recommendations were published last month in JANIA, and you have a copy of that publication.
They also were published in a somewhat longer version, in the Journal of Public Health Management and Practice.
These recommendations have been presented to a number of groups, including the Council of State and Territorial Epidemiologists, the National Association of County and City Health Officials, the Association of State and Territorial Health Officials, the American Public Health Association, AMIA itself, Netinfo, which is the triennial international conference on medical informatics.
As I mentioned, these have previously been presented to the NHII work group. So, that is all I have to say, and I would be happy to answer any questions.
DR. COHN: Maybe I can ask a question. Personally, I appreciate the review of the meeting. I was there and I thought it was an excellent meeting.
I think really what the subcommittee needs today from you, though, unfortunately may be addressed tomorrow by either your boss or one of your colleagues at CDC.
I think really what we wanted was any reflection or overview, recognizing the climactic events of this year, and I think the new urgencies around public health, in relationship to the letter we are writing.
I was just curious if you were prepared or wanted to share any thoughts, recognizing that this afternoon is when we have really to spend revising this document.
Tomorrow, we will be happy to take comments but we might not have really a lot of time to consider them, if it requires any substantive changes.
DR. YASNOFF: Let me say that the letter was circulated at CDC. I have not received any substantive comments.
However, I don't know what is going to be said tomorrow by my colleague. So, there may be additional comments.
I will say that, as you might imagine, folks at CDC are somewhat preoccupied. So, it is not always possible to get responses to these things.
I think folks are familiar with the work that is being done here. They have been briefed on numerous occasions. The PMRI report was widely circulated and commented upon.
I think CDC, as a whole, is very supportive of this work. It is clearly very important to CDC's objectives.
Standards not only will facilitate issues that we are all very familiar with within the health care system. Obviously, they will greatly improve our ability to receive information in a timely and accurate fashion from the health care system, to improve our ability to detect disease patterns earlier.
So, I think that the framework certainly is consistent with what CDC is doing. I believe you will hear more about it tomorrow.
I don't think there is anything in the letter that is going to be a serious problem for CDC.
DR. COHN: I guess the question, in my view, was if there was anything we were missing. That sounds like it is an open question that we will deal with tomorrow.
DR. YASNOFF: I think that the areas where help is needed relate to things that are beyond the scope of the letter, and primarily have to do with these governance functions and how we are going to build a national health information infrastructure that is coordinated, where that coordination is going to come from.
Really, these issues relate more directly to the NHII work group. I believe they are in the process of finalizing their report, which turns out to be quite timely.
DR. COHN: Other questions or comments? Thanks. All right, I think we are shifting now to a review of the letter. Kepa or Susan, do you need a few minutes to set up?
MR. BLAIR: John Lumpkin commented on the latest draft of the letter, and I thought I had distributed it to everyone. Is that correct?
Actually, I think John Lumpkin responded, as I recall, to the subcommittee. So, did you all see his comments?
MS. BURKE-BEBEE: I didn't.
MR. BLAIR: Is there anyone else who did or didn't?
DR. YASNOFF: I don't think they were included in this latest handout that we saw. I don't think I saw specifically John's comments either.
DR. FITZMAURICE: I believe -- were they identified as his comments.
DR. YASNOFF: I assumed they were included in this latest handout.
MR. BLAIR: I didn't make a separate copy or distribute them, apparently. I guess not, since nobody has gotten them.
To correct that oversight, he simply indicated that he felt very comfortable with the letter. The area that, in particular, caught his interest was the one where we philosophically are moving more toward guidance and less toward a mandate.
He felt that that was the right direction, but he didn't have any additional thoughts at that time. I think the key word that he had was that he felt that was the right direction, and he hoped that we would give it real careful thought, as we went through the discussion of the letter. So, that was his feeling.
He probably wasn't aware of the fact that Clem had also focused on that. I think it kind of parallels the additional sentence that we added there reflecting Clem's thoughts.
DR. MC DONALD: I was just saying that we didn't want to say that we wouldn't suggest any way to encourage the standards, but rather, would suggest further things that government could do related to maybe their use, government-related contracts, there is a whole slew of things.
It wouldn't be like the first round, where you put it up or you died.
DR. COHN: The letter is actually up on the screen. Shall we go through it paragraph by paragraph?
DR. ZUBELDIA: We have the version with the changes that Suzie did a couple days ago, version three.
MR. BLAIR: Do you have the one dated 12-11?
DR. ZUBELDIA: Yes, that is the one.
MS. BURKE-BEBEE: The date on the copy that I have is December 11.
DR. COHN: Mine says November 29.
DR. MC DONALD: There is one after that.
DR. ZUBELDIA: This is the one I got from Jack.
MR. BLAIR: Could I clarify that? When we sent it to you electronically two days ago, the file was dated December 11. Apparently, we had overlooked correcting the date at the top of the letter, and it still was indicating December 29.
If you will notice, it has all the changes in it, and in fact it is the correct one.
DR. COHN: So, we are all right.
DR. MC DONALD: Can I suggest we change the date to today before we even start in, and save frequently, because you can expect the computer to fail?
DR. YASNOFF: Yes, change the date to the 13th. That way, we can distinguish it from the other versions, assuming we were going to make some changes.
DR. COHN: So, Kepa, do you want to start out reading the first paragraph, or would you like to have us read the first paragraph? Why don't I start off reading the first paragraph and we will go paragraph by paragraph, allowing people to both wordsmith and change conceptual issues as we go through.
The first paragraph starts: Dear Secretary Thompson. As part of its responsibilities under the Health Insurance Portability and Accountability Act of 1996, the National Committee on Vital and Health Statistics was called upon to "study the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of such information."
The NCVHS presented this report to the HHS Data Council on August 9, 2000. This report provided a framework to accelerate the development of PMRI standards, and a set of guiding principles for the selection of specific PMRI standards.
The report also recommended that the NCVHS use the guiding principles for selecting PMRI standards, and send the first set of PRMI standards recommendations to the Secretary of HHS by February 2002.
This letter sets forth recommendations for the first set of PMRI standards, which are generally referred to as PMRI message format standards.
Are we all okay with this introduction? PMRI needs to be indicated.
DR. YASNOFF: The first time it is used. Under 2000 is the first time it is used, so write it out and put PMRI in parenthesis.
DR. COHN: Actually, it is in the quote above.
MR. BLAIR: It is in the quote above. Why don't you put it in the parenthesis in the quote above.
DR. FITZMAURICE: You have to put it in brackets. Otherwise, you are changing the quote.
DR. COHN: Okay, great. Second paragraph, then.
Standards for PMRI are important, because they are essential for the creation of a national health information infrastructure, which promises to facilitate significant improvements in the quality of patient care, control rising health care costs, enhance the productivity of clinical research, improve patient safety, and strengthen the nation's ability to identify and respond to national health care emergencies.
Comments? Bill?
DR. YASNOFF: Do you want to mention improving patient safety a little bit earlier in the list?
DR. COHN: Right after quality of patient care?
DR. YASNOFF: Right after quality of patient care, improve patient safety.
DR. FITZMAURICE: Alternatively, you could take out the essential for the creation of a national health information infrastructure, and then add another sentence at the very end saying, they are essential for the creation of a national health information infrastructure. That would be set out as important on its own.
DR. YASNOFF: I like linking them together. That is one of the things that is always unclear, I think, to many people is what the national health information infrastructure really promises. I think this says that in a nice way.
DR. COHN: I guess the other question on all of this stuff -- and I agree with it as far as it goes -- I was just sort of wondering, is the only reason we are positing that the PMRI standards are important is because they are essential for the creation of the national health information infrastructure?
DR. YASNOFF: No.
DR. COHN: That is what this paragraph says.
MR. BLAIR: Maybe we should tie the first two sentences together, where you say the national health information infrastructure, including all the other characteristics.
DR. FITZMAURICE: That subsumes.
DR. COHN: The way this reads now is that the reason PMRI standards are important is because they are essential for creation of a national health information infrastructure. Then we are also saying, the national health information infrastructure is a really good thing.
The question is, is there anything -- for example, these things are important because of the possibilities of being able to promote further administration simplification.
DR. MC DONALD: I don't want to diminish the NHII but many of those things, whether or not it happens, the standards can help. It can help safety, it can help standards.
DR. ZUBELDIA: Why don't we put in something that says, which promises to facilitate significant improvements in the quality of patient care, in parenthesis.
That would refer to NHII. Then, what we have is a list of benefits of PMRI.
DR. YASNOFF: Given that point, I would go back to Mike's idea. That is to say, standards for PMRI are important because they will facilitate improvements in the quality of patient care, improve patient safety, et cetera, et cetera.
They are also a key element in the creation of a national health information infrastructure.
As you point out, even without such an infrastructure, I think these standards would go a long way in all those areas.
MR. BLAIR: Kepa, I am going to let you kind of go ahead and make those changes that were suggested. Then I would like to suggest one word change at the end. Why don't I wait until you have made them.
[Changes made to letter as noted.]
DR. YASNOFF: How strong a statement can we make about the link between standards for PMRI and all those benefits? Can we say will or should we say are expected to? I don't particularly like the wording, promise to.
Promise is like, people tell us this. I guess we believe it.
DR. FITZMAURICE: A will would do it, instead of promise.
DR. YASNOFF: I think we said that in our original PMRI report. Jeff, do you remember that? Did we say that PMRI standards will facilitate all those good things, like patient safety?
MR. BLAIR: I think so.
DR. YASNOFF: I think we already said that.
MR. BLAIR: The people who wrote that document really knew what they are talking about.
DR. YASNOFF: That is what I have been told. I have been promised that.
MR. BLAIR: So, we can quote them.
DR. FITZMAURICE: I would also take out the also. I wouldn't put it here as an afterthought. They are essential.
DR. MC DONALD: I think you want also because it is a parallel. It is going to do this, it is going to do that.
DR. FITZMAURICE: I was trying to make them be sort of the same thing.
DR. YASNOFF: How about promote, Kepa, promote patient safety, so we can use a different word?
DR. COHN: I think it is fine.
MR. BLAIR: I think right now, in the last sentence, we have the word essential, related to NHII. Is that right? Can I pile on with everyone else, making this stronger, and say that it is critical?
DR. MC DONALD: Would crucial be better?
DR. COHN: What are our choices of words here?
MR. BLAIR: Clem suggested crucial, I suggested critical, imperative, whatever you like.
DR. MC DONALD: Essential for is not good.
DR. FITZMAURICE: Would you consider fundamental?
DR. YASNOFF: How about the word, prerequisite? The problem with that is, that makes it separate from, but an essential prerequisite to.
What I am trying to get at is that PMRI standards are a key step on the road to.
How about a crucial building block in our national health information infrastructure?
DR. COHN: Let's see. We have fundamental, essential prerequisite?
MR. BLAIR: Ingredient?
DR. COHN: Essential building block.
DR. MC DONALD: Essential building block is two words. You don't get it out as fast.
DR. YASNOFF: Are we being taxed on the words?
DR. MC DONALD: It is where Hemingway would complain.
DR. COHN: I think I am going to stay out of the word smithing discussion.
DR. YASNOFF: I like critical, actually, if we are going to substitute one word.
DR. COHN: Okay, let's go with critical. So, you will change things further as we go along, but are we okay here?
DR. YASNOFF: Shall we read it back for Jeff?
MR. BLAIR: No, it is okay, thanks, as long as you guys can read it and it is coherent. Thank you, though.
DR. COHN: Okay, next paragraph is process to select PMRI to select PMRI standards.
The NCVHS used the following process for the selection of PMRI message format standards, to obtain industry input from standards development organizations, the health care information system vendors, and the institutional users of these standards.
First, the committee modified the PMRI guiding principles to make them more appropriate for the selection of message format standards.
Next, the committee incorporated the revised guiding principles into a questionnaire, which was designed to help evaluate the PMRI standards candidates in a more objective manner.
Finally, the committee compiled, analyzed and reviewed the SDO's responses to the PMRI questionnaire.
Additional information and perspective about the candidate PMRI standards was obtained by a direct testimony from health care information system vendors and other users of these standards. This process continued from December 2000 through February 2002.
DR. YASNOFF: The word that bothers me in this paragraph is modify. The committee modified the PMRI guiding principles.
I read that and I think, well, wait a minute. You said you had these guiding principles, and the first thing you did, you changed them all around. It sounds too strong.
Can we say customized or something less drastic? Adapted is even better, yes, adapted. That makes it clear that the principles really are the same. We just kind of reworded them to be more applicable.
DR. COHN: I actually had a question about institutional users of these standards, and exactly why we are referencing the -- I guess we talked to the STOs, IT vendors and institutional users of these standards.
DR. MC DONALD: Which part is troubling you?
DR. COHN: I think it is the institutional users. I thought maybe the institutional -- to me, that just means hospitals.
DR. MC DONALD: Institution is any big thing. That is clearly not a synonym for hospitals. It could be nursing homes.
Do you want to say organizational users, health care organization users or health provider users?
DR. COHN: I guess I was just mulling over what we were referring to there. Are we talking about users?
DR. MC DONALD: We basically asked institutions, larger organizations, to come and people talked. We can't verify if they are actually computer users or whatever they are.
DR. ZUBELDIA: It says other users of the standards.
DR. YASNOFF: Simon, what is your objection to institutional users?
DR. COHN: I just thought institution was a little too limited. I am just trying to think of who --
DR. MC DONALD: Institution is too broad and too narrow. We could be talking about church institutions.
DR. YASNOFF: How about organizational representatives of users.
DR. MC DONALD: But they are health care.
DR. YASNOFF: Health care organizations representing users.
DR. MC DONALD: I think it would be easier to talk about health care organizations. We didn't really vette people on what role they had in their organizations. We asked them to send somebody to talk.
DR. YASNOFF: We asked organizations that represent users, to come talk to us.
DR. FITZMAURICE: User organizations?
DR. MC DONALD: No, not user organizations.
DR. YASNOFF: I wouldn't say that. Where, for example, is AMA in this. AMA is not an institutional user. They are a representative of people who use these things, maybe.
DR. ZUBELDIA: Maybe call them users of the standard.
DR. FITZMAURICE: Maybe institution really does capture it.
DR. ZUBELDIA: Or representatives of user of the standards.
DR. YASNOFF: I don't like just saying users, because that makes it seem like we had individual users, and we really didn't.
DR. MC DONALD: We had big organizations.
DR. YASNOFF: We had organizations that represent users.
DR. MC DONALD: Let's say we had Mayo come. Then we have to also say -- we just had big organizations and people would have to infer.
Their main goal isn't being a user representative. Mayo's main goal is to be a health care institution. I think we are maybe overdoing this. If we just want to say, we had some big other players here. Who did we have here? Maybe an example would be clearer.
DR. YASNOFF: The problem is, if you read this sentence, none of these categories where the American Medical Association fit in, I guess the Dental Association, in a sense, is an SDO.
DR. MC DONALD: Maybe we should say two things, health care organizations and professional societies. That capture the AMA and it captures --
DR. YASNOFF: Health care organizations and professional societies? That sounds good to me.
MS. BURKE-BEBEE: Is that a user?
DR. YASNOFF: Then it shows that we have never talked to the users.
DR. MC DONALD: The health care organizations are the ones who mostly --
DR. YASNOFF: I understand.
MR. BLAIR: We still have vendors in there; right?
DR. COHN: Yes.
DR. YASNOFF: Health care information system vendors, health care organizations and professional societies.
DR. ZUBELDIA: And institutional users or not?
DR. MC DONALD: I think it is fine.
DR. COHN: I think we have added the groups that I found myself sort of wondering about.
DR. YASNOFF: That covers everybody now.
DR. COHN: Since we are not getting paid by the word, we don't have to put ourselves in jeopardy on that one.
MS. BURKE-BEBEE: We may want to think about that same thing when we get to the next page, where we talk about health care institutions again. What about industry?
DR. YASNOFF: Industry is a little restrictive.
DR. ZUBELDIA: How about users, just other users.
DR. COHN: Okay, and other users, maybe.
DR. YASNOFF: That covers just about everybody I can think of.
DR. COHN: I think this is very good.
DR. FITZMAURICE: Can I move on to the next sentence?
DR. COHN: Sure.
DR. FITZMAURICE: I would like to have it read, the committee incorporated the revised guiding principles into a questionnaire that was designed to help NCVHS evaluate the PMRI standard candidates in an objective manner.
DR. COHN: Which sentence are you talking about?
DR. FITZMAURICE: The next sentence.
DR. COHN: Where it says, first, comma, you are changing that?
DR. YASNOFF: The sentence that starts next, comma.
DR. COHN: Read that again. We were on the wrong sentence.
DR. FITZMAURICE: I am sorry, the sentence beginning next. After help, I would put NCVHS and, instead of, in a more objective manner, I would put, in an objective manner, would strike a more and put an. More objective than what?
DR. YASNOFF: Than if we didn't have the questionnaire.
DR. ZUBELDIA: Where did you put NCVHS?
DR. FITZMAURICE: To help NCVHS. The committee then incorporated the revised guiding principles into a questionnaire that was designed to help NCVHS evaluate the PMRI standard candidates in an objective manner.
DR. YASNOFF: Did you delete the comma after questionnaire?
DR. FITZMAURICE: Yes, I would delete the comma after questionnaire.
DR. YASNOFF: I don't think Kepa did. Thank you. Grammatically, that must be very bad. Grammatically, the computer doesn't like it.
DR. FITZMAURICE: Having the comma which was bad.
DR. COHN: I move we go to the next sentence. How many hours do we have for this? We are doing okay.
DR. ZUBELDIA: Are we going to the next paragraph?
DR. YASNOFF: I was just trying to get to the next sentence. The next paragraph is fine, too.
DR. FITZMAURICE: That sentence beginning finally, I would put reviewed in front of analyzed.
DR. MC DONALD: I thought most of these guys had a chance to review this already.
DR. YASNOFF: That doesn't make sense.
DR. FITZMAURICE: You have to review something before you analyze it; right?
DR. YASNOFF: No, you have to analyze something before you review it. You compile it, analyze it, and then review the results.
DR. FITZMAURICE: You look at the SDO responses in order to compile and analyze them.
DR. COHN: I actually agree with Bill on this one. It is not worth a long fight. Let's go on to the next sentence.
DR. FITZMAURICE: You would analyze them before you review the responses?
DR. YASNOFF: You review the analysis.
DR. COHN: Anything on the next sentence? Okay, so we are done with that paragraph. Mike, you will have your chance again, don't worry.
Guiding principles used as criteria for selection. The NCVHS recommendations for PMRI standards are selected from the six SDOs that responded to the PMRI questionnaire.
Hopefully, these will at some point be footnoted or written out, since these are the first time they are seen. These include ASTM, DICOM, HL7, IEEE, NCPDP and OMG/Corbomed. We need to find some way of writing those out.
The committee emphasized the following four criteria derived from the PMRI guiding principles. The degree of market acceptance of the standard, the extent to which the standard enables interoperability between information systems, the ability of the standard to facilitate the comparability of data, and the aspect of the standard that supports data quality, data accountability and data integrity.
The criteria of market acceptance was very helpful. It identifies those PMRI message format standards that are implementable, cost justified, and flexible enough to meet the needs of the most relevant marketplace.
DR. YASNOFF: Sorry, it should be criterion, singular. It was plural and it should be singular, because we are talking about one.
DR. FITZMAURICE: Since we are talking present tense instead of the past tense, I would put is very helpful, or is helpful. I would strike the very.
DR. COHN: Okay. In the sentence above, maybe rather than data quality, data accountability and data integrity, maybe it is data quality, accountability and integrity.
DR. YASNOFF: I would suggest that we actually write in the paragraph the names of all those organizations, not right now, but Kepa, maybe you could put a note in there to spell out.
I am not going to expect the Secretary to necessarily have a working familiarity with all these acronyms.
MR. BLAIR: Simon had suggested that we do it as footnotes.
DR. YASNOFF: That is why I am bringing it up. I don't think it should be done as a footnote. I think it should be right there in the body of the letter. Otherwise, it may not be read.
MR. BLAIR: Here is my thought. The folks that need to work with this and read this, if they have to read through huge long sentences, rather than give them the option of finding it in a footnote but not forcing them to wade through it, to read through it if they don't wish to.
DR. YASNOFF: What I am thinking is we can put the acronyms in and then put the information in parenthesis, so people can skip it if they don't want to see it. I am worried about the footnote.
DR. MC DONALD: I think his point is, we will add another paragraph of text there, and they may not read the letter. I think that is Jeff's point. I think the point is that --
DR. YASNOFF: Create six footnotes?
DR. COHN: Another suggestion, since we have a colon there, why don't we bullet each one as a list of six, and break up this paragraph, since it is pretty dense.
DR. MC DONALD: Or make a table?
DR. COHN: So that people can see them quickly, rather than spend four lines there. Does that make sense?
DR. YASNOFF: I think that is a good compromise. Make bullets out of these, and then you can skip them easily, but all the information is right there. I am worried that footnotes will be ignored.
DR. COHN: I think that will be a little more pleasing to the reader.
DR. ZUBELDIA: Then spell them out.
DR. COHN: Spell them out and put parenthesis.
MS. BURKE-BEBEE: I suggest you do the acronym first and then spell it out, so that people who already know can just breeze through it.
DR. COHN: Are we okay otherwise? Okay, move on to the next paragraph. Better save that file now.
Next paragraph. Recognition of current standards and incentives for emerging standards. The NCVHS recommends that HHS recognize the important role played by the current -- and in parenthesis, de facto -- standards.
Recognizing that it takes years to develop standards with broad market acceptance, many of these standards lack the degree of interoperability and data comparability that the NCVHS PMRI report identified as necessary to support significant improvements in health care costs, quality and productivity.
To address these requirements, the NCVHS recommends that HHS provide several incentives to accelerate the development and early adoption of more advanced PMRI standards.
These incentives complement recommendations three and four as described in the PMRI report to the Secretary, presented to the HHS data council on August 9, 2000.
Comments, before I jump in here?
DR. FITZMAURICE: It says role that is played by these current, parenthesis, de factor, standards. Some of them are not de facto. Some of them are actual American national standards.
DR. COHN: Maybe we ought to get rid of de facto.
DR. FITZMAURICE: I would get rid of de facto.
DR. COHN: Is that okay with everyone?
MS. BURKE-BEBEE: I thought we talked about de facto as being an important part of this, in the past discussions that we had.
DR. COHN: Maybe it is one or the other.
MR. BLAIR: Let me just give you the reason that I put de facto in. If you want to get rid of it after I explain it, that is fine.
When I went through the hard copy testimony from October 9 and 10, I think at least three quarters of the vendors and users referred to them as de facto standards. That was the primary reason.
The other reason was that we never were able to get definitive data which reflected market acceptance, the level of market acceptance of standards.
I thought de facto was a supportive phrase, and one used by the industry. That is the only reason that is there.
DR. FITZMAURICE: I think it tends to exclude American national standards.
DR. COHN: What about saying current and de facto.
DR. MC DONALD: The same thing. I think there is an issue but we are confusing some of the meaning. The ones we are talking about mostly are formal ANSI approved standards. So, they are not classical de facto.
I think what they were saying in their testimony was, for the matter of practical purposes or something, they are everywhere. Being a formal standard doesn't make it accepted either.
DR. COHN: We have got DICOM which is not an ANSI standard.
DR. MC DONALD: The word de facto was to be a positive thing to describe these standards that are in place. The problem is that it takes away from the fact that they are not really de facto standards, like the IDM card that was put in.
DR. ZUBELDIA: The current standards in use.
DR. COHN: The currently implemented standards?
DR. ZUBELDIA: That could cover both meanings.
DR. YASNOFF: At the end, where it says PMRI report to the Secretary, I would delete everything after PMRI report, because it is redundant, just PMRI report.
We already said in the first paragraph that it was delivered to the Secretary and presented to the HHS Data Council on that date. How many times do we need to say the same thing.
I know we are getting paid by the word, but this seems excessively redundant.
DR. COHN: I guess the question is, not to give us any less pay because we are going by the word -- although we are not going by the wording -- but I am not sure I remember what recommendations three and four are.
If I have a hard time remembering them, I have a hard time believing that recommendations three and four are.
DR. YASNOFF: That is a separate point. I think telling the Secretary that it was presented to the HHS Data Council on that date is not going to help his memory. He was not the Secretary then, in any case.
DR. COHN: I guess the question is, should we actually put recommendations three and four there.
DR. FITZMAURICE: Or have it as an attachment. See attachment A.
DR. COHN: What are those recommendations?
DR. ZUBELDIA: I agree with Mike, that is a great idea. Just give him that report again that has already been officially presented, and it is now included here as an attachment.
DR. YASNOFF: Yes, that is a good idea.
DR. COHN: That is a very good idea.
DR. YASNOFF: So, would you say here, in the attached PMRI -- when you refer to it, we need to go back to the first paragraph. After 2000, put attached.
MS. BURKE-BEBEE: We are attaching the whole report?
DR. YASNOFF: Well, he wasn't the Secretary when we presented it.
DR. COHN: I think it makes a lot of sense to send it back to them.
DR. YASNOFF: Do we still want to say recommendations three and four?
DR. COHN: Yes, what are those recommendations? The question is -- I am wondering, if we are attaching this whole thing, do we really need to specify the recommendations, or do these incentives complement recommendations described in the attached PMRI report.
DR. FITZMAURICE: We probably need to tie it more specifically to those recommendations.
DR. YASNOFF: Also, do we really mean that the incentives complement or that they are consistent.
MR. BLAIR: It is that the recommendations in this letter complement the incentives. There are some words that were left out of that sentence there. It is that the recommendations complement the incentives.
DR. YASNOFF: Isn't what you are trying to say that the recommendations in this letter implement --
MR. BLAIR: Let me go back, please, if I can. Let's look at what the purpose of this paragraph is, because maybe we need to make some corrections here.
Recommendation two indicated that NCVHS would select specific standards. That tends to support the first objective of this paragraph, which is recognition of the current standards.
Recommendations three and four relate to things that could support or accelerate emerging standards. Specifically, three is the one that said HHS will take immediate action to accelerate the development of PMRI standards, and the early adoption of those standards.
It had the six sub-items of all the different things, which we tend to draw upon later in the letter, and that is why we say this letter is complementing those previous recommendations.
Recommendation four also wound up saying that HHS should fund implementation guides, conformance tests and government licensure of clinically specific terminology, for those standards that were selected.
DR. YASNOFF: When you say complement, that, to me, means that you are extending or you are doing more than in the recommendations, when really what you are doing is implementing.
MR. BLAIR: Reinforcing or implementing.
DR. YASNOFF: What you are saying is that these incentives, the recommendations in this letter represent the implementation of the original recommendations in the report relating to X and Y.
DR. FITZMAURICE: I think it is actually an echo, not an implementation. It isn't implemented until somebody gives money to somebody to do something.
It reinforces those recommendations. We are saying it again, and putting it into a context.
DR. YASNOFF: These recommendations provide specific implementation steps for recommendation so and so, the recommendations relating to X and Y in the original report.
MS. BURKE-BEBEE: One of the concerns I had as I read this was, why would you identify two? Are they better?
DR. COHN: Two of the recommendations versus others? Yes, I agree.
MR. BLAIR: It is that we draw upon those two recommendations later, when we wind up saying either what the industry should do or what the government should do to support emerging standards.
MS. BURKE-BEBEE: It just made me wonder about it.
DR. COHN: Yes, it is just general recommendations. Let's just take a look and see what Kepa has done here.
DR. YASNOFF: What it says now is, the recommendations in this letter provide specific implementation steps for recommendations three and four as described in the attached PMRI report.
DR. COHN: And rather than recommendations three or four, the recommendations related to something.
MR. BLAIR: Is that the beginning of the paragraph?
DR. YASNOFF: No, it is the end. The sentence before that is, to address these requirements, the NCVHS recommends that HHS provide several incentives to accelerate the development and early adoption of more advanced PMRI standards.
The recommendations in this letter provide specific implementation steps for recommendations three and four as described in the attached PMRI report.
MS. BURKE-BEBEE: I think we lost something. The original sentence, which was the last one that we modified, was referring to incentives, which was the previous sentence.
So, to address these requirements, the NCVHS recommends that HHS provide several incentives to accelerate the development of early adoption.
Then, we said, these incentives, when we referred to recommendations three and four. I don't think we were referring to all the recommendations in this letter, but just specifically the incentive ones.
DR. YASNOFF: Right, from emerging standards.
MS. BURKE-BEBEE: We moved on to something different.
DR. ZUBELDIA: This change I just made. The incentive recommendations in this letter --
DR. COHN: The incentives recommended in this letter?
DR. ZUBELDIA: Yes.
DR. COHN: Provide specific implementation steps.
MS. BURKE-BEBEE: So, it says, these incentives recommended in this letter -- the incentives recommended in this letter implement recommendations three and four. No, that doesn't make sense to me.
MR. BLAIR: That is where I said -- maybe this isn't right -- the recommendations for incentives in this letter implement.
Suzie, is that where we should say, the -- the word incentives is -- the word recommendation is left out of there. The incentives recommended in this letter implement?
DR. FITZMAURICE: We could just say they follow the recommendations three and four. The word follow is the same as are consistent with.
DR. COHN: That is actually much better, except probably follow recommendations three and four. These incentives -- the incentives recommended in this letter follow recommendations three and four as described in the attached PMRI report.
DR. FITZMAURICE: I would consider taking out the word several. Recommends that HHS provide incentives. I am not sure that several adds anything to that.
I think if they have new ones or better ones, they should implement them; that is, the Secretary should.
MR. BLAIR: On this particular section, it really would help me keep it in context if maybe, Simon, could you reread the entire paragraph or section?
DR. COHN: Sure. Just don't make me read the entire thing from the beginning.
Standards. The NCVHS recommends that HHS recognize the important role played by the currently implemented standards.
Recognizing that it takes years to develop standards with broad market acceptance, many of these standards lack the degree of interoperability and data comparability that the NCVHS PMRI report identified as necessary to support significant improvements in health care costs, quality and productivity.
To address these requirements, the NCVHS recommends that HHS provide incentives --
MR. BLAIR: I think we should say also recommends, because we are recommending two things. We are also recognizing the role of the current standards, and we are also recognizing the need for incentives.
DR. FITZMAURICE: I would take out the "the" in front of NCVHS because we don't have a "the" in front of HHS.
DR. COHN: What is the other recommendation?
MS. BURKE-BEBEE: We have got the recommendations here.
DR. COHN: I am just looking to see what the other recommendation in the earlier part of the paragraph is.
DR. MC DONALD: I think it stands by itself.
DR. COHN: I don't think there is an also there.
MR. BLAIR: So, when we are recognizing the current standards, we didn't state that as a recommendation.
DR. COHN: I guess it recommends that HHS recognize the important roles of the other --
MR. BLAIR: Yes, that is the first recommendation.
DR. COHN: I am not sure that is much of a recommendation.
DR. FITZMAURICE: That is not a recommendation.
MR. BLAIR: Let me get to Clem, because I tried to parallel it this way.
DR. MC DONALD: I think there may be some other words, but I think there are two things there, and we are just trying to say both of them clearly and they are parallel.
We are using the word recommends in the first one, HHS --
DR. FITZMAURICE: No, Jeff is right, now that you point it out. There is an also.
DR. MC DONALD: I think we have lost something by taking out de facto. I don't think we have the same meaning there, even though de facto wasn't the right word.
MS. BURKE-BEBEE: I think so, too.
DR. MC DONALD: I think what you really want to say there is the current standards that have been adopted by industry. Those are the standards that you are talking about.
DR. ZUBELDIA: You are saying that were implemented.
DR. MC DONALD: Implemented doesn't mean anything. It is adopted by industry. That is what he meant by de facto.
De facto has a shade that means it could not really be a real standard, but that is really what he is going to go on and talk about.
I would say currently adopted by industry, or if you could make that straighten out, you would be okay, too. The standards currently adopted by industry would be the simplest way. I think that is what you are trying to convey with de facto.
DR. FITZMAURICE: And we do accept the PMRI standards, because in the whole paragraph where we talk about standards, we don't say which ones.
I would put, recognize the important role played by the PMRI standards.
DR. COHN: By industry, by the health care industry?
DR. YASNOFF: By the health care industry, that is good.
MS. BURKE-BEBEE: I like that, that is good.
DR. COHN: Since we are doing major work on this paragraph, maybe you can all help me with the next sentence, which I think is a little odd, but I am not sure if I know how to change it.
MR. BLAIR: Could you read it for me?
DR. COHN: It says, recognizing that it takes years to develop standards with broad market acceptance, many of these standards lack the degree of interoperability and data comparability with the NCVHS PMRI report, identified as necessary to support the significant improvements in health care cost, quality or productivity. Maybe we need to get rid of the part before the comma.
MR. BLAIR: Here is the point I was -- let me tell you what I was trying to achieve with that, and then maybe there is a better way to do this.
We wanted to do two things. We wanted to recognize the importance and value of the current standards, and we wanted to point out that it was unrealistic to expect that the current standards would have all of the attributes we were looking for, for the future, because it takes so long to be able to develop them and implement them.
So, that sentence was trying to give an explanation for why the current standards might not have those attributes and therefore were also going to recognize emerging standards.
MS. BURKE-BEBEE: The other thing, to address what you were saying, Simon, when I read this, if I would take out recognizing, up to the comma, it made me think, well, why in the world, if I was the Secretary, why in the world would you be recognizing any standards that don't have broad market acceptance. That gave me an understanding of the rest of --
DR. COHN: I guess I am confused by what you were just saying. I don't know why taking it out to the comma --
MS. BURKE-BEBEE: You are saying, I am recommending the PMRI standards that are adopted, and many of these standards don't yet have the degree of interoperability and data comparability that NCVHS' PMRI report identified as necessary to support.
My question is, well, then why are you recommending them. That sounds like a negative to me.
DR. MC DONALD: I think what it is really saying is, these aren't the final perfection you could achieve in all the universe of time.
DR. BURKE-BEBEE: I think we need to say it better, though.
DR. MC DONALD: We set some very high standards. You are right. We are saying, why bother -- the truth of this whole thing, if industry doesn't use them, it doesn't matter what our theories are about these things.
I think the thing is, we have set some very, very lofty --
MS. BURKE-BEBEE: We need to say this nicely.
DR. YASNOFF: So, what you are suggesting is that we say something like, recognizing that it takes years to develop standards with broad market acceptance, it is important to build on the capabilities of existing standards to support significant improvements, blah, blah, blah.
MR. BLAIR: That is a different point. Whether it builds on it or not, I feel as if the key point on this, the key message to get through to the Secretary, who doesn't need to get into the details of this, is to say, we need to recognize the current standards.
You also need to understand that we can't expect that the current standards would have all the attributes that we want for interoperability in the future.
So, in addition to recognizing the current standards, because they have market acceptance and, therefore, great value, we also need to make recommendations for incentives to accelerate the emerging standards.
That keeps it direct and simple and two-pronged. If we add build on, that is a third dimension that could make the paragraph much more complex.
DR. MC DONALD: The ideas are good, but I think this concept is very complicated to express on a piece of paper.
DR. COHN: I think the problem that I am having, as I read this, as I am going through, gee, these standards have been around for a long time. Yet, even despite that they have been around for a long time, they don't do sort of what we think they need to do. So then, why would I build on them.
I don't think that is what we mean. I think what we need to do -- I think Bill actually was closer in the sense -- and Wes also -- about the idea that we are saying, gee, it takes a long time to get to even where we are now, and what we want to do is to build on a good foundation to make things even better.
DR. MC DONALD: To get to the final goals.
DR. CONN: Or to get to a more advanced goal.
DR. YASNOFF: The other thing we are trying to say is that, there needs -- if we wait, if we just leave things alone and wait, that we are not going to get where we want. That is why we need to provide these incentives.
DR. MC DONALD: Can you fix that? Can you capture that? I think this is a hard sentence to write as a collective here.
DR. YASNOFF: Let me suggest, I will take a crack at that. Why don't you move on, and I will take out my computer and work on that and we can come back to it.
MR. BLAIR: Could I suggest one thing, as you do your variation, Bill? It may be helpful to break it apart into separate sentences for the separate points.
The only piece that I was concerned about is from the standpoint of educating somebody who is not familiar with the industry and familiar with these standards.
I think the separate point that I don't want to get lost is that market acceptance has great value and the current standards have that.
We cannot expect them to have all the characteristics we want in the future, because it takes so long to get to the stage of market acceptance.
DR. MC DONALD: I think Bill has got to get a shot at it.
DR. COHN: Shall we go on to the next paragraph? Have we had enough chewing at this one?
PARTICIPANT: If you could go back up, Kepa, it says, these incentives recommended in this letter. I don't think we recommended any actual incentives. I think we asked that they consider incentives, but I don't think we recommended anything.
MR. BLAIR: When you get down to the HL7 pieces and you get to the emerging areas, we recommend that HHS do the things from recommendations three and four.
MS. BURKE-BEBEE: You have incentives to accelerate the development and early adoption of HL7 version three.
These incentives include the funding of version 3.0 implementation guides and conformance tests and the early adoption of version 3.0 standards by departments and agencies within HHS. That is one under emerging standards.
MR. BLAIR: Right, that is one recommendation and that is right out of recommendation four.
DR. COHN: I guess we will have to see if that is the only recommendation. We can sort of keep our eye on that, to see how many recommendations we really have.
Recommendations encourage guidance rather than mandates. The NCVHS recommendations for PMRI message format standards advise that HHS set forth guidance for industry use and migration to new versions, rather than the creation of NPRMs and federal regulations.
NCVHS also recommends that the Secretary direct government health care institutions to follow this guidance, by becoming early adopters of emerging PMRI standards, thereby serving as an example and as an incentive to the industry. Comments?
MR. BLAIR: That additional sentence that we add there, that happens to also be recommendation 3F from the PMRI report.
MS. BURKE-BEBEE: That is where I mentioned the institutions, did we want to keep the term institutions there as well.
DR. COHN: Actually, that is the place where it is probably actually appropriate. So, are we okay with that paragraph?
Okay, next paragraph. NCVHS recommendations for specific PMRI message format standards. NCVHS recommends that HL7 be recognized as the core PMRI standard, and that NCPDP script, IEEE 1073, and DICOM be recognized as standards for specific PMRI market segments.
The recommendations for the core PMRI standards are set forth in a framework that identifies which version of the standards should be considered as retired, current or emerging.
DR. ZUBELDIA: The comment that I have is that I am not sure that IEEE 1073 is ready for adoption, when IEEE themselves qualified it as an emerging standard.
MR. BLAIR: This particular paragraph is referring only to HL7, but maybe we should change that.
DR. ZUBELDIA: I don't have any problem with recommending that NCPDP script and DICOM be recognized as a standard for a specific PMRI segment. It is the IEEE.
DR. COHN: Clem isn't in the room right now. Maybe we should hold that until Clem is in the room and we get to that paragraph. We can either handle it here, or we can handle it when we are looking at the specific recommendations about that. Is it okay to defer that, and then we will figure out what to do with this?
MS. BURKE-BEBEE: Can I make just one comment about that to you, Kepa?
DR. COHN: Sure.
MS. BURKE-BEBEE: Because the standards are grouped into three different areas, I thought that it would be okay.
DR. COHN: We don't know what area that IEEE 1073 even should be in. Let's defer the IEEE comment, or are you referring to something else? Are you referring to the IEEE?
MS. BURKE-BEBEE: Yes.
DR. COHN: Okay, let's defer the comment about IEEE. I think Kepa is really wondering whether it should be removed entirely from the whole letter, which is a whole different discussion.
DR. FITZMAURICE: Just a small point in the paragraph above. I would capitalize S in front of Secretary. I wasn't sure if that had been capitalized or not.
DR. COHN: We will get back to it. There is a whole paragraph on IEEE here. Why don't we deal with it when we get to it here.
So, retired standards. The NCVHS recommends that HHS recognize the following PMRI message standard as retired, and this is HL7, version 2.1.
Industry guidance. No new products, using this version of the HL7 standard should be purchased or developed. Vendors and users should plan to upgrade any system using HL7 2.1 to a current version of HL7, and there is a comment here, should this have a designated period or time frame.
Comments otherwise about this section? I actually think it is fine, personally, without giving any period or time frame in there.
MR. BLAIR: I agree with you, Simon.
MS. BURKE-BEBEE: That was my comment. The rationale behind it, I remember when Woody was here and testified and we did talk about the issue of how long a version would be used, and then we talked about the fact of compatibility.
We also talked about version 3.0 wasn't backward compatible. That issue, I thought, possibly was being lost here.
MR. BLAIR: Deadlines for compliance don't appear to be our strong suit.
DR. COHN: Anything else on this one? Okay, current standards. The NCVHS recommends that HHS recognize the following HL7 versions and transaction sets as the current PMRI message format standard.
This is HL7 version 2.2, 2.3, 2.4. This includes standards for the following: transaction sets, order entry, scheduling, medical records/image management, patient administration, observation reporting, patient administration/financial management, patient care.
Then we have industry guidance, HHS recognition of HL7 version 2.2, 2.3 and 2.4 as current standards means that vendors and users of these versions will not be asked to migrate to newer versions until the more advanced version is fully implementable, with the supporting implementation guides and conformance tests.
DR. ZUBELDIA: Picking up on the comment that was made this morning, I think we should say 2.2, 2.3, 2.4 and later in the 2.X series.
DR. COHN: And later 2.X versions?
DR. ZUBELDIA: And later 2.X versions, or subsequent.
MS. BURKE-BEBEE: The point that was made, I wrote this down -- Wes, you are still here -- as long as the establishment of extensibility stays in place.
MR. RISHEL: [Comment off microphone.]
DR. COHN: I think this is actually looking pretty good up here. Do you have an issue?
MR. RISHEL: I just wanted to say why I added those things. My feeling is, everything that I added in those qualifications is really implicit in saying version 2.x, because that is the process HL7 goes through. It uses extensibility. It gets their versions ANSI certified.
The only reason to add any complicating language would be if the committee wanted to be sure that it was defensible in terms of endorsing something that is not there to look at yet.
DR. COHN: So, you are in agreement with what we have written up there?
MR. RISHEL: I think that is fine, unless you feel the need for more.
DR. COHN: Is everyone okay with this? Jeff, what we have written up here is, in parenthesis, where we talk about HL7, we have got version 2.2, 2.3, 2.4 and later version 2.x, maybe version 2.xs. We will let them word smith that Xes or the X. Other comment here?
DR. ZUBELDIA: Is this list of messages the right list?
DR. COHN: I am sorry that Dr. McDonald is not here. He might be able to advise on this. It looks like the right list.
DR. ZUBELDIA: We have gone through it several times.
DR. COHN: It is time for a break. Does everyone feel like they are ready for a 10-minute break? Okay, we are going to break for 10 minutes.
[Brief recess.]
DR. COHN: Where are we now?
DR. ZUBELDIA: Now that Clem is back, are we going to revisit this?
DR. COHN: About the IEEE? Actually, I was going to suggest we do it where we talk about standards for specific PMRI market segments, and we figure out how to do it there.
I think what we are asking, Dr. McDonald, is to make sure that we had the HL7 transaction sets right, which was --
MR. BLAIR: The sets that are represented there are the ones submitted by HL7.
DR. COHN: Okay, and I think we have made the modifications to the industry guidance, including the versions V2X later in the current standards. I think at that point we had stopped.
DR. ZUBELDIA: These are the correct names, like patient care is the name of a message?
MR. BLAIR: Yes, those are the ones submitted from HL7 in their response to the questionnaire.
DR. COHN: Now, let's take a look at emerging standards. The NCVHS recommends that HHS recognize the following PMRI message format standards as an emerging standard based on its potential to provide superior levels of interoperability and data comparability.
We have here HL7 version 3.0. This includes standards for the following transaction sets: administrative management, health and clinical management, infrastructure management.
Recommendation to HHS. NCVHS recommends that HHS provide incentives to accelerate the development and early adoption of the HL7 version 3.0 standards.
These incentives include the funding of version 3.0 implementation guides and conformance tests, and the early adoption of version 3.0 standards by departments and agencies within HHS.
Then, industry guidance. Once HL7 version 3.0 is considered to be formally implementable, additional HHS guidance to the industry is expected. Now, comments?
DR. ZUBELDIA: Is the version 3.0 already fully implementable?
DR. COHN: I don't think so.
MR. BLAIR: The first ballot was issued. They expect to go through two more ballots. The guidance that I have gotten -- Clem, you can clarify this -- is there will be a demo at HL7 in February, another demo in May.
There were some testifiers who indicated that they were going to go forward including it in their own products, but the general guidance that I have heard is that it will be the second quarter of next year before it will be considered implementable. Clem, what do you know?
DR. MC DONALD: We should distinguish implementable from approved. The implementable, you can implement it at any time. I think it is implementable. In fact, it is probably very implementable.
DR. COHN: Maybe fully implementable is not the term we want to use there.
DR. ZUBELDIA: Maybe fully approved as a standard or fully balloted?
DR. COHN: I don't think that is what we were saying either. I think we were sort of saying that it has been approved by the industry, and HHS has identified that it really is as described, and there may be additional guidance, I think is what we are saying.
DR. ZUBELDIA: The way it reads, it sounds to me like there is some deficiency with version 3.0 that is not implementable.
DR. MC DONALD: That is not the case. There are messages and everything. Maybe you can say, all the messages have not been defined for all of the version 3.0, so that is another issue. It is fully implemented, maybe.
DR. ZUBELDIA: Maybe fully developed.
DR. MC DONALD: That has got the same problem.
MR. BLAIR: My thought is that the criteria here should be that NCVHS does not come out with further guidance until the industry considers, on a general basis, that version 3.0 is fully implementable.
If we start to encourage people a year or two or three from now, we would encourage them to move to something that people say yes, it is fully implementable. It works.
DR. COHN: Basically you are saying, once HL7 version 3.0 is considered to be fully implementable by the industry, the NCVHS will provide additional guidance to HHS and the industry?
DR. ZUBELDIA: I don't think you are talking about implementable. I think you are talking about adoption. Once version 3.0 has widespread adoption, then there will be further guidance.
MR. BLAIR: Then, they don't need us, if it is already widespread -- I think it is the point at which it is ready for widespread adoption.
I thought the words, fully implementable, we would wind up saying, okay, you can begin to implement it widely now.
MS. BURKE-BEBEE: I think what separates it from the current standard is just that. Kepa, if you go up and you see the industry guidance for the previous current standards, see the last three lines of that where it says, users of these versions will not be asked to migrate to newer versions until there is a more advanced version. The more advanced version is fully implementable with the supporting implementation guides and conformance tests.
To me, that is defining what implementable means. Do we really want that to carry over into emerging? I thought emerging didn't have to have that criteria, because emerging --
DR. MC DONALD: Is emerging now. He is saying when it is no longer emerging. That is consistent, I think. The question is -- fully developed, I think, could almost be -- what I would probably want to say is fully developed and has some real implementations, but I don't know how to say that.
MS. BURKE-BEBEE: You mean demonstration?
DR. MC DONALD: No, I mean, I think the truth is, you don't want -- the rule on the internet standard is that it is never a standard until you have got two things implemented and being used, two different versions of it.
You wouldn't really want to push something on any part of the industry that hadn't been used by some part of the industry, hadn't been sort of shaken down by real life use.
I think the thing we would like to get at is that it is fully developed and it has some industry use.
What you are trying to say is you want to have some real experience that it does work and people will want to use it. Then you work faster, so that there becomes closure.
MS. BURKE-BEBEE: But not quite the criteria for the current; is that correct?
DR. MC DONALD: No, no, the current -- well, I don't know if we need to quibble about that. They have to have some industry use, not dominant industry use, but some industry use, so that we know we are not getting a pig in a poke.
DR. ZUBELDIA: Why don't we say version 3.0 has industry use. Additional HHS guidance is expected.
DR. MC DONALD: Some industry use maybe. It is fully balloted and there is some industry experience, maybe, with it. These are hard. These are hard shades to get.
DR. COHN: What we are seeing is that there are a couple of things we need. We need the implementation guides. We need the conformance tests. We need early successful use by industry, almost along the lines --
DR. MC DONALD: Some early adoption of the standards.
DR. COHN: Some early adoption. Then, we would make recommendations where additional HHS guidance would be forthcoming.
MR. BLAIR: We said, and successful early adoption. Once we have seen that some of the early adopters are successful, that is the threshold when we could make our recommendations, yes, industry, go forward with this.
DR. COHN: Don't you need the implementation guides and the performance tests?
MR. BLAIR: Yes.
DR. MC DONALD: We could still have both of those.
MR. BLAIR: The implementation guide, conformance testing and successful early adoption.
DR. COHN: That is good. Kepa, did you want to include the implementation guides?
MS. BURKE-BEBEE: Supporting implementation guides and conformance tests? Is it resulting in successful early adoption if you have those others? I am just thinking aloud.
DR. MC DONALD: I think those are three separate things. Conformance tests and some successful early adoption by industry.
DR. COHN: Question. In the paragraph above, we talk about the early adoption of version 3.0 standards by departments and agencies in HHS.
On page one, we added a new sentence. I am trying to see if they are redundant. Actually, they are not. Forget my comments. Anything else here?
DR. ZUBELDIA: Can you read the sentence?
DR. COHN: I am withdrawing my comments. Okay. Once there are implementation guides, conformance testing and successful -- maybe conformance tests?
MR. BLAIR: Early adoption.
DR. COHN: We are talking about testing. Once there are implementation guides, conformance tests and successful early adoption of HL7 version 3.0 by the industry, additional HHS guidance to the industry should be expected?
DR. ZUBELDIA: Should be forthcoming.
MS. BURKE-BEBEE: Will be.
DR. COHN: Will be forthcoming.
MR. BLAIR: Here is a piece, and maybe you could glance over the letter. I think that when we first drafted the letter, we thought we were making a recommendation for HHS to recognize each of these levels, and then I think we slid in our words to the idea that maybe it was NCVHS that does the recognition, and we wind up asking HHS for the incentives.
Could someone please glance through to see if we have lost our consistency on that?
DR. COHN: Do we want to say additional NCVHS and HHS guidance to the industry will be forthcoming?
DR. ZUBELDIA: Or just NCVHS guidance?
MR. BLAIR: Okay, NCVHS guidance and HHS -- yes, will be forthcoming. Let me just run that by Clem for a second. Does that ring true for you, the idea that it is NCVHS that gives the guidance, but it is HHS that provides the incentives, and we are recommending that HHS provides the incentives?
DR. MC DONALD: I think you are saying the only thing we can say at this time. We say it is our intention to do further tuning, specifically, when this occurs, the NCVHS.
Then, the HHS comes out as we say it. This sentence sounds right. The actor in this sentence sounds right.
MR. BLAIR: Maybe what I need to do is go back to where we say industry guidance. In the phrases on industry guidance, do we say it is NCVHS or HHS that does industry guidance?
DR. MC DONALD: We could be saying, at the present time, please, HHS, give them guidance. In the future, all we can say is that, given this guidance all we can say in the future is we can revisit this, is what we are sort of saying.
DR. COHN: I actually think that overall things are fine. Okay, shall we go to the next section? Standards for -- yes?
AUDIENCE: I am not real familiar with the HL7 funds, but I just was wondering, are they being asked to consider the funding of the creation of implementation guides, what an SDO does, just right above where your line is?
These incentives include the funding of version 3.0 implementation guides?
DR. COHN: What is your question? I am confused.
AUDIENCE: Is HHS funding --
DR. ZUBELDIA: Is it the funding of the implementation guides or is it the funding of the implementations?
MR. BLAIR: We should be asking -- our recommendation should be that HHS fund the implementation guide conformance tests for HL7 version 3.0
DR. ZUBELDIA: HHS funds the writing of the implementation guides, which is normally done by the SDOs. I mean, that is going to be a big challenge. There are hundreds of volunteers who participate in the writing of the implementation guides.
MR. BLAIR: How did we do it with X12?
DR. ZUBELDIA: That is funding the publication of the implementation guides, the publication of version 3.0 and publication rights.
MS. BURKE-BEBEE: Okay, but then read the rest of it at the end. Does it still make sense, and the early adoption of version 3.0 standards by departments and agencies within HHS?
DR. MC DONALD: I think the funding doesn't apply to all. There is sort of a different comma you need in there or something.
We should maybe put that first. These include the early adoption by -- so it doesn't get confused.
DR. COHN: Maybe there is a colon that needs to be there.
DR. MC DONALD: If you bring the ones that aren't subsumed by funding up front, that would clear it up.
DR. COHN: So, are we funding the publication of conformance tests or are we funding conformance tests or are we funding the development of performance tests?
DR. MC DONALD: Development is what we have said all along. We need these conformance tests across the board.
MS. BURKE-BEBEE: And development of?
DR. COHN: Yes. Obviously, the commas and the colons and semi-colons will be fixed there. Kepa, I don't think that is your responsibility.
DR. ZUBELDIA: These incentives include the early adoption of version 3.0 standards by departments and agencies within HHS, the funding of the publication of version 3.0 implementation guides, and development of conformance tests.
MR. BLAIR: Do you have version three in that sentence?
DR. ZUBELDIA: At the very beginning, version 3.0 conformance tests. Is that what we are talking about?
MS. BURKE-BEBEE: It says, these incentives include the early adoption of version 3.0 standards by departments and agencies within HHS, the funding of publication of version 3.0, implementation guides, an development of conformance tests.
DR. COHN: Okay, let's go on. DICOM supports retrieval of information from imaging devices/equipment to diagnostic and review work stations, and to short and long-term storage systems.
So, basically I think we have asked to remove the 3.0 and the 2000 and just describe this as DICOM. Kepa, you are losing us here.
DR. ZUBELDIA: I am trying to accept these changes.
MR. BLAIR: I think Todd was recommending to us that we refer to it as DICOM version 3.0.
DR. COHN: Todd was actually IEEE. I think he was referring to it as DICOM.
DR. ZUBELDIA: DICOM, no version 3.0, no 2000.
MR. BLAIR: Sorry. I got my IEEEs and DICOMs confused.
DR. FITZMAURICE: You could leave the dashes after short and long, for short term and long term.
DR. MC DONALD: Could you go back to the sentence just above that, ready and implementable, the first line, I think.
I think the principle of the thing is that they have been adopted, or have industry acceptance or something.
MR. BLAIR: Don't we already have that in there?
DR. MC DONALD: Well, implementable.
DR. ZUBELDIA: Currently adopted?
DR. COHN: Widely adopted?
DR. MC DONALD: Widespread industry adoption, I think.
MR. BLAIR: We can't say that yet for IEEE.
DR. COHN: Let's get to IEEE.
MR. BLAIR: Or NCPDP script yet necessarily.
DR. COHN: That is a good point.
MR. BLAIR: What I was trying to do was wind up saying -- there should have been or in that sentence, and/or.
DR. MC DONALD: Implementable is not very strong.
DR. FITZMAURICE: They passed a test.
DR. MC DONALD: It isn't very strong. I think the real reason why we are interested in it is because of industry acceptance, maybe that is the right word.
MR. BLAIR: We can't say that -- we were just informed that IEEE doesn't have it, and NCPDP script is partial, and it is growing.
DR. MC DONALD: They mentioned that --
MR. BLAIR: If we do it that way and say market acceptance alone.
DR. MC DONALD: We say a number of things. The key thing is not implementability. Then we would have 50 standards on this thing.
DR. FITZMAURICE: It is the fact that they are used.
MR. BLAIR: How are you suggesting that we phrase the sentence then?
DR. COHN: Look at what Kepa has up there -- which I will have to read for you, Jeff -- to see if we are close. It says, basically, the NCVHS recommends that HHS recognize the following as PMRI market segment message format standards, based on their ability to address specific market segment needs, cost effectiveness, and the fact that they are currently adopted by the corresponding industry segment. That looks better than it sounds.
DR. MC DONALD: I think that is good, actually.
DR. COHN: The question is, does it need the final and, or is it their ability to address certain market segment needs and cost effectiveness. Maybe that is all that really we need to have up there.
DR. MC DONALD: I can list you another 10 supposed standards that we have to put up there, if we don't get a tighter screen on it.
We have said many times that, based on the experience -- especially based on the experience we had with the earlier standard development and NDC language, we said, well, if it is not adopted by the industry, we can't force it on them.
DR. COHN: Clem, maybe we need to hold this conversation and look at IEEE and NCPDP script and then go back and see how it fits in with this.
I could argue any way about this stuff. What you are saying certainly applies to DICOM, but the question is, what do we do with IEEE and what do we do with NCPDP script, since we have those as additional recommendations, and we had better make whatever we want to say consistent with what we want our recommendations to be. Is that okay? So, we will hold that.
I know that Kepa has had some concerns about IEEE 1073. Shall we read it and consider what we want to do with it, as well as word smith as needed.
DR. ZUBELDIA: We are done with DICOM, then?
DR. COHN: I think we are done with DICOM, yes. So, IEEE, 1073, a set of medical device communication standards also known as ISO 11073 standards communicates patient data from medical devices typically found in acute and chronic care environments -- e.g., patient monitors, ventilators, infusion pumps, et cetera. It says in parenthesis, IEEE should be considered an emerging standard.
If that is the case -- I don't know what to do with this whole section, but what are people's views on this?
I guess I have one thought. I seem to only have one thought late in the day here. My personal question is, it certainly appears to me, based on the testimony, that 1073 is not a mature or a -- what was the term we were using -- a current market segment standard.
The only question is whether it is even an emerging market segment standard. I don't have enough information to make that judgement.
The question is, do we need to get testimony or do we need to get written support from others in the industry that they consider this to be the right emerging market segment standard? I think that is the question.
DR. MC DONALD: I had actually had the impression that it was used, but I didn't hear any of that in the testimony. We should have cross examined.
They said, these vendors were on the committee, and they said they were using the SEN standard. They said a lot of those things. I didn't hear them say, we have got 10,000.
DR. ZUBELDIA: They did describe several vendors that are using it, and there is one that was going to implement the full 1073. I don't have the names in front of me, but they did mention that there are some that are using it today.
DR. COHN: Let me just pull out my notes here. Actually, I think they said that nobody was using it and the question was not appropriate because it was not implemented yet.
DR. MC DONALD: They held it back until they got it systematized with SEN.
DR. COHN: I apologize, let me see.
DR. MC DONALD: They withdrew or pulled it back for a while.
DR. COHN: Here we go. These standards would correctly be classified as emerging. Therefore, there is no extensive marketing activity possible.
A number of data points, though, do show market support for the standards. You have got the Biosys Health Care recently announced that their next generation ventilator will only support 1073 interfaces.
Then the next bullet says, major device companies are members of the working -- as well participate in the 1073 working meetings, and there was a group of vendors that were involved in the working meetings.
These companies are working together on these standards to address real market needs and issues that they face on a daily basis.
The issue is, do we send them a letter and ask them whether they are actually implementing these things or whether they are still developing them.
I think that is really the question. I think that is what you are asking, too.
DR. MC DONALD: If they have 50 hospitals using it, we would stay where we are. If they had nobody using it, this is not right.
DR. COHN: I think we could easily enough ask the vendors. The question is, do we want to ask the vendors. Do we want to send a letter to the vendors who are members of this. I guess Siemans was there. I didn't see Hewlett-Packard, is the other one.
DR. MC DONALD: Is it being marketed and installed, is what we want to know.
MR. BLAIR: As I recall back from advice we were given by vendors and users on October 9 and 10, they were asking us to play the role of a catalyst, to move things forward.
I think, in the case of IEEE, there doesn't appear to be an alternative for message format standards for the medical devices.
I think that there certainly is an open question as to -- forgive my word -- about how implementable it is, or how widely the market will accept it.
I think that maybe we could play an instructive role by at least including it in the letter as an emerging standard.
Whether we ask HHS to provide any funding for implementation guides and stuff like that, I don't feel ready to go to that extent yet.
I do think we play a proper constructive role to move the industry forward if, by listing them as an emerging standard, we encourage greater market acceptance for it.
DR. MC DONALD: I don't think our role is that. I don't think our role is to push the market to something it didn't want.
I think what we could maybe do is make that be another section and say we will provide further advice. The thing I am really confused by now, what you read verbatim was, they are not there yet.
Maybe we should get more information. I actually didn't understand that was the case.
DR. ZUBELDIA: That is what they said.
DR. COHN: I tried to ask them that.
DR. MC DONALD: It isn't a published standard, and we are saying that is a problem, let alone market acceptance.
DR. ZUBELDIA: It is a published standard, but it is a standard that has changed in the last couple of years, and they don't have the permutations yet.
DR. MC DONALD: I thought he said they held back this new version of the standard until they got it aligned with some other things.
DR. COHN: Remember, I asked the question, I had heard it had been around 10 years and how come you are still describing it as an emerging standard.
I think that, based on his recommendation, I don't think we can go further, even on whatever information that we have, beyond saying that it would be an emerging market segment standard.
The question is, I think we need more information to know whether it is even that. I don't feel I have enough information to say that, which I think is what Kepa was sort of commenting about. I think your view was to just strike the whole thing.
DR. ZUBELDIA: Take it out.
DR. COHN: The question to me is, I don't have enough information, and I don't think Clem has enough information, based on your comments.
The question is, do we send a letter out? Do we ask a couple of the vendors to come and testify about what they see this as?
DR. MC DONALD: We could do it as a letter. If we knew what they are marketing currently, some sense of the sales, the market penetration, how many institutions have installed it.
DR. COHN: If we are talking about an emerging standard, and recognizing that we are talking about things that are on the inside of monitors and ventilators, I mean, people could implement this thing and not even know that they are implementing it.
DR. MC DONALD: No, not at all. Right now, you have got a special wire and everything.
DR. COHN: Oh, is that right? I take that back.
DR. MC DONALD: That is what they are trying to get away from. Everything is special.
DR. COHN: Isn't the question really, for these vendors, are you implementing it in your systems, or do you plan to implement it in your systems?
DR. MC DONALD: Well, plan to, I don't think is going to give us what we want. Are you implementing it and who is buying it?
DR. COHN: I guess I would argue with that. If their comments are, well, gee, we are going to be implementing in six months to a year, then maybe it is like version 3.0 of HL7. That is an emerging standard. It is not there yet.
DR. MC DONALD: It would be like version 3.0 if version 1.0 was in there and being used. I mean, I didn't hear it as clearly as you just wrote it when you said what you said, that it isn't appropriate to be considered market accepted, because it isn't out yet.
MR. BLAIR: I didn't hear that it was being used.
DR. MC DONALD: I didn't hear them say it was being used, but I still thought it was. I had in my mind that it is out there.
DR. COHN: I think the reality is -- this is just my recollection -- that many of us who have been involved in the standards community over the last 10 years have seen presentations and various activities around 1073 previously.
I think many of us sort of figured that it had entered the mainstream of use.
DR. MC DONALD: The thing to do is to send some letters to people in the community and ask them, is it now in any of their products, and do they have -- can they count -- we don't want their market secrets, but some sense of what percentage of their sales are using it.
If we get even small numbers, we have got a clear idea. If we get zeroes, then Kepa's version is right.
DR. COHN: What do you think? Does it make sense to send out a letter to both the IEEE just to reconfirm our understanding and ask for a couple of vendors to respond?
DR. MC DONALD: They gave us the five vendors who they said were on the committee.
DR. ZUBELDIA: The concern that I have is that, if we recommend the Secretary adopt this, we may end up in a situation where we are recommending something that doesn't really exist yet.
DR. FITZMAURICE: Suppose I call Todd and find out if he considers this an emerging standard.
DR. MC DONALD: That is not the question. We don't want to know, in terms of our new code word, what an emerging standard means. We want to know what the situation is on the ground.
That is, are any vendors now marketing this standard. That is number one. Number two is, is anybody buying. Are there any installs.
MR. BLAIR: We are asking them to be more explicit about vendor acceptance and usage.
DR. MC DONALD: The business, they have accepted it, yes, everybody signs on, yes, I accepted it. We have to know who is actually investing and building stuff with it.
You would like to know if they are marketing it now. It is going to be dangerous, I think, to be recommending a standard that no one -- we based this on some kind of industry usage, at this stage.
We might want to mention, anyway, but in another section, that we will follow this closely. Right now, I think we need to know what the facts are.
MR. BLAIR: Would the subcommittee feel okay if, in order to expedite without further inquiry, if we handled it as an e mail directly to Todd Cooper saying the subcommittee would like more explicit information about those vendors that either have implemented IEEE 1073, or are planning to implement it.
DR. MC DONALD: Not the planning to.
MR. BLAIR: Have implemented it.
DR. ZUBELDIA: Have not implemented it is not enough by itself. We need to know who is buying it and who is using it. If it is implemented in a ventilator but nobody is actually using it, they really don't know.
MS. BURKE-BEBEE: I think if there had been, we would have heard about it today, because we heard about it from the others.
When you read the answers to the questions from Todd, there is nothing in there. He refers to one major supplier of a ventilator.
He then talks about implementation guides and he talks about prototyping and demonstration projects. There is nothing in this -- and I think there would be -- if there was anything out there.
MR. BLAIR: In order for a standard development organization, for IEEE 1073 to be able to come up with those implementation guides -- this is voluntary -- it means that they do have vendors who are actively participating in developing these standards. There has got to be a certain amount of --
DR. COHN: I just don't think we have enough information yet. I agree with Jeff, that we need to go out and ask a couple of questions. I think Todd is a good person to ask.
DR. MC DONALD: We need answers like we got from the script.
DR. COHN: I guess the questions are, you know, have you implemented it already, a version of 1073. Have you announced.
DR. MC DONALD: Are you marketing it.
DR. COHN: Are you marketing it. Probably another question is, have you announced that you are going to be implementing it in the next three to six months.
DR. MC DONALD: See, that is so soft.
DR. COHN: This helps us, though.
DR. MC DONALD: It doesn't. I see vendors come in today, like three months ago, saying they use IEEE Medix. They just slap every single one on there.
DR. ZUBELDIA: For the last three years we have seen vendors saying that they are HIPAA compliant.
DR. MC DONALD: I think what we want to learn is, does it exist now today, not is it a thought, not is it a hope.
DR. COHN: Clem, let me just make a comment, because I think asking that other question would be helpful. I think the question that we are dealing with right now is, is it an emerging standard for a market segment, or is it in a new section called on the horizon.
It may very well be that IEEE gets into a paragraph toward the end of the letter which says, this is an important area, this doesn't appear yet to be an emerging standard, but we will advise you as soon as we feel there is enough use to be describing at which point we feel it might be appropriate to put the full weight of the U.S. Government behind moving it from an emerging to a current standard.
DR. MC DONALD: The only problem with us defining questions, even on discussion, in terms of the phrase emerging standards, we just made it up today.
There is nothing wrong about that. It is just that it is like, are you a good person, yes.
If you ask them specifically, are you marketing this product now -- you can ask all three, you can ask any of the questions. Who has bought it or how many places have bought it.
I think if no one has bought it, I think we have got problems with making a recommendation.
MR. BLAIR: I think Simon is suggesting that we ask about plans to market, in addition to all the other questions that are more solid. Then we can see the difference when we get the answer. Is that right?
DR. COHN: Exactly. Bill?
DR. YASNOFF: The fellow from IEEE testified that this is an emerging standard.
DR. COHN: We are wondering whether it is even an emerging standard, is the discussion.
DR. YASNOFF: Is the issue whether, if we classify it as an emerging standard, then we are recommending that the Secretary provide incentives for people to migrate to it?
DR. COHN: Yes.
MR. BLAIR: That would be another implication. If it is emerging, do we wind up recommending the implementation guides.
DR. YASNOFF: Just because we classify it as emerging, where does it say that we have to recommend to the Secretary that identical incentives, if any, apply to all emerging standards.
MR. BLAIR: It doesn't say so in the Torah. That is the only thing I am familiar with, or the Bible.
DR. YASNOFF: I don't think it says anything about PMRI standards in any of those documents.
DR. COHN: Bill, I think the question that we are asking is whether or not it is even an emerging standard and whether we want to identify it as such, regardless of whether or not we give incentives.
DR. YASNOFF: What is the down side of identifying it as an emerging standard if it never emerges?
DR. COHN: It might cause people to move toward it who might not otherwise move toward it.
DR. ZUBELDIA: We have a paragraph at the end of the letter that says, PMRI standards for future consideration. Maybe it fits as a paragraph saying, this is for the future.
DR. YASNOFF: I don't understand what your concern is.
DR. COHN: It is a qualified recommendation.
DR. MC DONALD: The concern is that we won't be consistent in our recommendations. We have basically said, in many contexts, we are basing this on, in large part, we know it works; it is out there.
DR. YASNOFF: But HL7 version 3.0 doesn't work. It is not out there. There is no person who uses HL7 version 3.0. There is no system that claims to have it. No one has purchased it and it is not even specified. We are labeling it as emerging.
DR. MC DONALD: There is at least a version 1.0. I think when we are talking about this, it is a little less risky.
DR. YASNOFF: I am not arguing one way or the other. I think if you want to list it as things we are going -- I think if we are not sure, we should list it as things we are going to look at later.
DR. COHN: The question was, by asking a couple of questions, we could be sure.
DR. MC DONALD: Maybe it is out there. When I came in today, I thought it was out there, but I never saw one out there.
Then when I heard -- especially when you read the testimony -- even when I heard the testimony, I thought, I know it is out there, so I wasn't listening real hard. When I read the testimony it sounds like it hasn't been published yet.
Dr. YASNOFF: Rather than rushing, I think it would be better to delay. That is my suggestion.
DR. COHN: You are suggesting we put this under PMRI standards for future consideration.
DR. YASNOFF: Nothing is going to happen if, next April, we send the Secretary another letter that is three lines saying, by the way, we have investigated this further and we would like to add this to the emerging category. We are going to be sending a lot of letters like that.
MR. BLAIR: I think it would be helpful, if it is possible for us to get answers, where we could make a decision where it might be possible to include it in one letter. The impact, the visibility, would be helpful.
DR. MC DONALD: Why don't we save that paragraph and hold it down in that other place, and then we will get the information and we can readjust.
MR. BLAIR: If we send an e mail, we should get a response in January, and we should be able to make this adjustment by our early February meeting, Simon?
DR. COHN: Yes, and I am beginning to sort of agree that it is probably in that last PMRI standards for future consideration. Having said that, I think we are all open to new information.
DR. YASNOFF: As of this minute, that is where we put it, unless we receive additional information.
DR. COHN: Exactly. I think that answers, Kepa, your question about the first paragraph.
DR. MC DONALD: Are we almost done?
DR. COHN: We are getting close. We are going to do the NCPDP script. So, I guess you are getting rid of that section.
DR. YASNOFF: Do you want to do the script first, or do you want to go back? I have finished rewriting that other paragraph.
DR. COHN: Let's do script first and then we will go back to that other area. Okay, the next section is NCPDP script standard version 1.5 to 4.2.
MR. BLAIR: I think, from the testimony, they wanted us to alter that, so that --
DR. COHN: No, I think they consider them all standards.
DR. YASNOFF: 4.2 was the current standard.
DR. ZUBELDIA: There are some 1.0 hanging about.
DR. COHN: Are they compatible with each other?
MS. GILBERTSON: It is all the same syntax.
DR. COHN: Can they transfer messages back and forth with each other, interchangeably?
MS. GILBERTSON: Yes.
DR. MC DONALD: It seemed like you had great big huge gaps in your numbers.
MS. GILBERTSON: It has to do with our standard operating procedures. If there is a change to the addition of a data element, that might change a syntax. Therefore, it affects whether it is a version or a release.
If someone comes forward and wants a new qualifier added, it is a version or a release change.
DR. MC DONALD: This is not a criticism. It is just an observation. What I heard was 1.5, 3.-something and 4.2. That is all. It just came out that way, you are saying.
MR. BLAIR: I think the key point is that there is a continuity and that they are not separate versions. They should all be listed as current; is that correct?
MS. GILBERTSON: That is correct.
DR. MC DONALD: That is not what I heard in the testimony. I heard that 1.5 would be the current, in the final conclusion testimony, and the 4.2 would be emerging. I heard you didn't want to have to make people do 4.2.
MR. BLAIR: You heard correctly. Later on in the conversation it was altered that they are all current?
MS. GILBERTSON: NCPDP directed that, if I had to pick one to tell you, it would be 4.2.
DR. MC DONALD: That is not what your partner said.
MS. GILBERTSON: No, but when we read over the letter to the Secretary, there were multiple versions noted. For example, in the IEEE that was just deleted, 2.1, 1.2, 1.3, 1.1.1.
Well, there are features of each one of those. Are you recommending whichever feature you want, you pick whatever version you want.
As part of thinking through this morning it was, well, 1.5 is the one that was addressed as the one that was commonly used, but 4.2 is the one that NCPDP would like recommended.
If you were going to put a parenthesis after NCPDP script standard, it would be version 1.5, 4.2.
DR. ZUBELDIA: So, we would define that 1.5 is the current version with 4.2 being the emerging version, under the definition that we had for emerging.
DR. COHN: I actually heard that 4.2 was like a 2.X HL7 version, in the sense that there is not a big jump.
MS. GILBERTSON: My comment is that it is an emerging version and not an emerging standard.
DR. ZUBELDIA: So, none of them are a big jump. If somebody is going to implement from scratch, they should implement 4.2, because it is the current one.
DR. YASNOFF: What we are trying to do, what I thought we were trying to do in our letter was to provide guidance as follows.
If you are running a system with a standard that is retired, you are on notice that you are going to have to change it.
If you are running a system or you are acquiring a system that is in the list of current standards, you are fine and you don't have to do anything, and the emerging standards are the things you should watch for.
What we are trying to say by listing -- I think -- by not listing something as current, the message we are giving is, don't buy a new system, unless it has at least this.
So, do you want people to be buying systems that are version 1.5 now, or do you want them to be buying version 4.2 now. 4.2 doesn't exist as of this day; right?
MS. GILBERTSON: Correct.
DR. YASNOFF: So, the answer is, the most current version I can go buy today is --
MS. GILBERTSON: Is 4.0.
DR. MC DONALD: I agree absolutely with whatever you say, except that, given that there will be lags in this, what I think they want is 1.5 and 4.2 both.
DR. YASNOFF: Through 4.2.
DR. MC DONALD: I didn't hear that, 1.5 and 4.2, because no one used some of the middle ones. They don't want to get them out there. That is what you said, 1.5, 4.2. Why don't we just do that.
MS. GILBERTSON: As I said this morning, by the time HHS may have action on this, we could be at 6.3.
DR. YASNOFF: So, we should list those as current standards. That is the current proposal?
DR. MC DONALD: You are right, this hour they are not, but they will be by the time this filters through the process. We present this in February.
MS. GILBERTSON: By then, it will have been adopted.
DR. MC DONALD: So, if we say 1.5 and 4.2, then we should say something .X, like we do with HL7.
DR. ZUBELDIA: Let me caution here that we have already stumbled with the NCVHS version 5.1 that is being questioned by the pharmacy industry, because they are on 3.2 today and they are migrating to 5.1 and they have all these issues with privacy.
The 5.1 implementation guide had all the options of the elements. So, that is a different story, but I don't think we should do the same thing with script.
DR. YASNOFF: The question I am asking, or the point I am bringing up is, we are doing this to provide guidance to people who are buying systems.
So, what guidance do we want to provide? Do we want to tell people to buy systems with version 1.5?
DR. COHN: I guess what I am hearing is that maybe this guidance looks a little different from some of the other guidances.
I think what we are talking about is current. The reason why we are calling the HL7 version 3.0 an emerging standard is because it is such a big jump from where things are.
We would not be calling version 2.5 or 2.6 of HL7 an emerging standard, because they can slide into it. I think that is the paradigm that I am hearing.
Maybe what we need to be saying is that the current standards are 1.5 or 4.2. We are, a, advising people who have something before 1.5 to move up. We are also advising people who are buying new systems that they should be looking toward the most recent version of NCPDP standard to purchase.
DR. YASNOFF: We should say that as a separate sentence that says industry guidance.
DR. COHN: Exactly.
DR. YASNOFF: Purchasers of new systems should acquire them with the most recent standard.
DR. MC DONALD: We are trying to say something that people understand.
DR. YASNOFF: Exactly.
MR. BLAIR: Bill, I think the construct to provide consistent guidance, we can't seem to do that, in the sense that, like with NCPDP, we can't divide it usefully into retired, current and emerging. So, Simon's phrase, I think, is exclusive to NCPDP.
DR. YASNOFF: Right. In other words, we are going to say, NCPDP version 1.5 through 4.2 are all current standards.
Then there is an industry guidance sentence that says, purchasers of new systems should acquire them with the most recent version.
They are all current. They all talk to each other. They are not numbered the way that we would like, but they all talk to each other. If you are buying a system, you should buy the latest one. Is that wrong?
DR. ZUBELDIA: They don't quite talk to each other.
DR. YASNOFF: We are not telling people who have 1.5, we don't want to put them on notice that it is going to be useless.
DR. ZUBELDIA: No, but if you buy 4.2 or 4.0 today, and you want to talk to a pharmacy that only has 1.0, you can't, because it is going from a higher version down to a lower version.
DR. YASNOFF: I understand.
DR. MC DONALD: Nobody in the testimony wanted the whole spread proposed to be used -- help me with this -- because no one has adopted the middle ones, so that will just create additional confusion. Help me with this. I don't want to put words in your mouth.
DR. YASNOFF: What we want to say is that version 1.5 is the standard, or version 4.2, or whatever is the latest.
MR. BLAIR: I am not sure your statement was accurate, that no one has adopted any versions between those two extremes.
DR. MC DONALD: I am not certain either, but that is what I heard the testimony.
MR. BLAIR: That is what I thought, if Bill used the phrase 1.4 through version 4.2.
DR. MC DONALD: We can ask. NCPDP, tell us.
DR. YASNOFF: In other words, there are three things we can tell people. We can not list it, which means you are not really using a good standard. So, that is four things.
We can put people on notice and say that you have a standard, it is true, but your standard is so low, that you are on notice that it is going to be obsolete.
We can say, you have a standard that is current, keep it. We also need to tell people that, if you are going to buy a system, what should you demand from your vendor. Those are the practical things that we are trying to say, I think.
DR. MC DONALD: You have still got problems. I would like to still hear the answer, though. Are versions other than 1.5 and below used currently? I thought I heard that they were not.
MR. BLAIR: Below 1.5.
DR. MC DONALD: I don't know about below. But 3.0 wasn't used, is what I heard.
MS. GILBERTSON: I can't say unequivocally there is no one out there. I was aware that a company called Iscribe, that had a lot of implementation of the script standard, lost their venture capital funding just recently. So, those locations have shut down. They may have been at 4.0. I don't know for a fact.
At this point -- part of it is my thinking going one step forward which is, doesn't HHS take this and say, we are going to name one?
DR. MC DONALD: No.
MS. GILBERTSON: They are not going to do like they did with --
DR. MC DONALD: This is a soft standard requirement. This is not like the X12. That is the first paragraph.
DR. YASNOFF: We are trying to provide guidance to get people to do what we think they should do. So, we want to tell them, if they need to get a new system, and if they are getting a new system, we want to tell them what they should demand.
DR. MC DONALD: Bill, here is what is going to happen. I am a big HMO and I have got a contract with CVS or with Walgreens, and Walgreens is on 1.5. If I am going to do this, do I really want to get 4.2 because the guidance says I have to, because I am just getting into it.
DR. COHN: I am beginning to hear that maybe we really need to think of 1.5 as the current standard and 4.2 as the emerging standard.
DR. MC DONALD: I think it is easiest to just give those two and if you have another one -- find the numbers that you wouldn't want to invalidate, but let's not make it noisier by suggesting that people use stuff that no one is using.
MS. GILBERTSON: The recommendation was 1.5 and 4.2. If we have to name just one, 4.2 is where we want to point people to, as the guidance for where to go. It is not that much different from 1.5.
DR. COHN: Let me ask a question. Are we next month going to have 4.3 and the month after that 5.0, or is this going to be pretty stable?
DR. ZUBELDIA: It may be better to not define a version, and just say NCPDP script.
MS. GILBERTSON: And then use the guidance statement?
DR. YASNOFF: We would want to at least say 1.5 and higher.
DR. ZUBELDIA: That is something you hear from somebody from PDX which has implemented 1.0.
MS. GILBERTSON: We are not naming a version in DICOM.
DR. MC DONALD: They claim there are no versions. They erased the serial number.
DR. ZUBELDIA: Maybe we do not name a version and then provide industry guidance that you should go with version 4.2 if appropriate.
DR. YASNOFF: I like that idea, to say the existing standard is NCPDP script, and industry guidance, if you are purchasing this new, all other things being equal, you should try to use version 4.2 or the latest version.
How about, new users should adopt the latest version whenever possible. How is that?
DR. ZUBELDIA: As industry guidance.
DR. YASNOFF: So, it is a little sentence below, as industry guidance, new users should adopt the latest version whenever possible.
DR. MC DONALD: You can't go too far wrong with that.
DR. COHN: I am actually going to suggest, this is not for us today to do, but Mike and Jeff could, given that we are down to two standards in this area, rather than describing this as a whole section called standards for specific PMRI message market segments, given that we only have two market segments that we are identifying, maybe each of them needs to be culled out and each of them has to have industry guidance associated with it, since we only have two.
MR. BLAIR: I hope that we will still have a third after we get a response from IEEE. I personally would feel saddened if the letter goes forward without a recommendation for a standard that covers medical devices.
I think it is a very important area and I would hate for it to just be empty.
DR. MC DONALD: There is a lot of scratching to do there, Jeff. There are EKG machines which have their own standard, and that is a device. There are a lot of laboratory instruments that we used in HL7. There are some old ASTM standards that are still very actively used in laboratory instruments.
I think the bigger fear is that the early MIB had the problem that it was like a $4,000 set of chips and they had everything specialized in terms of special communication.
Now, what I heard was good on this latest thing is that they are talking about using the standard protocols and standard connectors.
It isn't there yet. I wish I didn't hear the testimony, in some ways.
MR. BLAIR: No, I wasn't saying that we should decide that way at this point. I think it is the right thing to do to solicit additional information. I guess I was just expressing my personal hope.
It would be nice if the information would make us feel comfortable. If it doesn't make us feel comfortable, then I think we have this other option, which is the on the horizon thing, which may be appropriate.
DR. COHN: Standards for future consideration.
DR. ZUBELDIA: I just made a little change here. We have DICOM without any industry guidance at all, and it is the same situation, that you have to use the latest one.
I upgraded the industry guidance to apply to both of them, by putting it under the bulleted section. It says, new users should adopt the latest version of these emerging standards, whenever possible.
DR. COHN: I don't think they are emerging.
DR. ZUBELDIA: How did we call them?
DR. COHN: Market segment standards.
MS. GILBERTSON: Just two or three lines above, it says three standards. I guess you need to note it is two, if IEEE goes down the page.
The other was, under this NCPDP script, this standard communicates prescription information between providers, period.
DR. MC DONALD: Wait a minute, that is major change. Does that mean providers on a hospital ward? If you just make it period -- the key thing here is the retail pharmacy.
MR. BLAIR: Between prescribers and retail pharmacies.
DR. MC DONALD: What are you trying to get to, because otherwise, you make it so broad.
MS. GILBERTSON: My original had the word prescribers in it, but I wasn't sure that you would like that.
DR. MC DONALD: The prescriber is all right. The other side is --
MS. GILBERTSON: The other side is the retail pharmacy. That precludes the fact that, if you don't consider yourself a retail pharmacy, you can't use script, which the inhalation pharmacies, the long-term care pharmacies, the specialty pharmacies do not quite consider themselves retail.
DR. MC DONALD: So, how do we qualify it without making it universal?
MS. GILBERTSON: You could say pharmacies. That would be safer.
DR. MC DONALD: Pharmacies is also hospital pharmacies. It sounds like it is covering a territory that had been segmented nicely.
MR. BLAIR: Could we put in parenthesis the list that you just gave us?
DR. ZUBELDIA: How about we say, between providers and certain pharmacies.
DR. YASNOFF: How about non-hospital?
MR. BLAIR: Non-hospital pharmacies, such as, e.g., and then identify.
DR. MC DONALD: I liked the -- if you just want to give your list.
MS. GILBERTSON: I hate to exclude anyone.
DR. MC DONALD: Leave it as a non-hospital pharmacy.
MS. GILBERTSON: A hospital pharmacy that performs outpatient services may want to perform script. It is the kind of function they are doing.
DR. MC DONALD: This is a segment and you have got to find the segment. If it is just doing all prescriptions, first of all, it is going to be a heck of a job getting that to flow through Script.
DR. YASNOFF: Are we talking about outpatient prescriptions only?
DR. MC DONALD: I don't know if we are even talking about outpatient prescriptions. When we do discharge prescriptions, the inpatient pharmacy does it. There is no Script prescription.
MR. BLAIR: We can just describe them as non-hospital pharmacies.
DR. MC DONALD: We have an attached nursing home.
DR. COHN: Unless you can come up with some really good words, which don't need to be done right now, I think we should leave it as retail pharmacies. This conversation has not added a lot to my understanding of the situation. I would welcome it if you had some wording you wanted to submit to Mike or Jeff. This is not the last time that we will deal with this.
DR. MC DONALD: We don't want to forbid anyone from doing anything. There are XML standards all over the place that are popping up, and so this doesn't say -- this is sort of encouragement for one area. It doesn't say you can't work your way into other areas.
DR. COHN: We will look forward to word smithing with you on that. Shall we move on?
DR. ZUBELDIA: This is what we talked about; right?
DR. MC DONALD: By the way, hit the save button.
DR. ZUBELDIA: This standard communicates prescription information between providers and retail pharmacies.
DR. COHN: Sounds good for now. Save the document.
DR. MC DONALD: Prescribers, I think, is a more specific word, prescribers and retail. Is that all right with you?
DR. COHN: Communicates prescription information between providers and retail pharmacies. Okay. You have added the industry guidance. Let's move on. We are actually moving forward.
This is probably a whole different section. The industry guidance, you have already done that, and you have added the new recommendation on industry guidance. New users should adopt the latest version of these market segment standards wherever possible.
Then we have got a whole other section here, where I should probably read this paragraph. It says, additional industry guidance. It may have another title.
It says: NCVHS encourages these three SDOs to harmonize their data elements and their data definitions for their future versions, so they are consistent with the HL7 reference information model.
Additionally, NCVHS encourages NCPDP and HL7 to continue their negotiations to reduce or eliminate duplication or inconsistent data elements, especially those for patient information.
NCVHS also encourages the ongoing negotiations between DICOM, IEEE and HL7, to harmonize the data elements within existing versions of their standards. Comments?
MR. BLAIR: Lynne suggested a better word than negotiations. What was the word you suggested?
MS. GILBERTSON: Collaboration.
DR. COHN: I personally think this paragraph needs major overhaul, based on what we have done before. Kepa, unfortunately, you now have changed three to two above and now we are talking about IEEE down there.
DR. ZUBELDIA: Two different things. We are talking about two SDOs above. The two SDOs, which are DICOM and NCPDP, need to harmonize their elements with the HL7.
Then, at the bottom, we encourage the ongoing collaboration between IEEE and HL7 to harmonize.
DR. COHN: Let me make the following comment. I am a little concerned about how we are -- I think the RIM is a major issue, a major opportunity also.
I think that maybe we need a paragraph that talks about what you are describing there, but also specifically mentions about the need to have the current HIPAA transactions, the X12 transactions, also work to harmonize with the reference information model.
Maybe provide input and harmonize, and I don't know what the right wording there is. I started off this conversation this morning saying, as I get older, I get more confused about what is administrative and what is clinical data.
Somehow, if we miss that opportunity, we have somehow missed a big opportunity, considering there is already work going on in HL7 in relationship to some of the administrative and financial activities.
DR. MC DONALD: I guess the question is if that would create political disharmony, or would it be better to put it down in the last paragraph, the last sentence.
DR. COHN: Somehow, there is a bunch of ideas here.
DR. MC DONALD: Two thoughts. One is, I don't have a sense of whether that is going to make this a more acceptable or less acceptable document to the community.
The second thought was, you definitely could put them down, the DICOM, IEEE, X12 and HL7, to harmonize. That would be a no brainer, the second thought in that paragraph.
DR. FITZMAURICE: Suppose we wrote it as general in the beginning of the paragraph. We want additional harmonization data elements and definitions and so forth, without naming names.
Then go on, we encourage negotiations between DICOM, IEEE, HL7 and X12, to harmonize data elements within their existing system.
In other words, good is good, and we want these people to continue doing good.
DR. ZUBELDIA: I think using the RIM as a converging point, I think it is positive. It is going to create a program for X12, because I don't think X12 can converge on the RIM. It would have to redesign all the transactions.
DR. MC DONALD: The other thing is, there is already ongoing discussion between the other two groups.
AUDIENCE: I had a question as I read this for the first time. I didn't really realize that we were being asked to go to the RIM. I was working toward the collaboration in USHIK.
DR. MC DONALD: What is USHIK?
AUDIENCE: The United States Health Information Knowledge Base.
DR. MC DONALD: That is softer.
AUDIENCE: I was wondering in what direction the organization is being recommended to collaborate with.
MR. BLAIR: I think she makes a very good point.
DR. FITZMAURICE: Except USHIK is a repository of data elements, but it is not an information model. You could have both.
It could be part of the RIM, part of an information model, and then your data elements would refer to the same concepts, whether or not you are part of RIM.
I think part of a reference model, whether it is RIM or something else, is better.
DR. YASNOFF: Putting your information in USHIK is just saying, here is how we do it.
DR. FITZMAURICE: Yes, it is a dictionary.
DR. YASNOFF: Harmonizing with the RIM means you might have to change how you do things.
DR. ZUBELDIA: It is HIFB's role to harmonize those?
DR. FITZMAURICE: The point is to take a picture so that people can look at the definitions for a given variable across different users, various definers.
It is not to say go to the RIM. It might be to say, gee, these are all different. Which ones would I pick if I had my druthers.
DR. COHN: Maybe we are talking about a couple of levels of recommendations here. I am hearing some things, including things by one of the standards developers that didn't even think about the RIM up until this discussion.
That is very appropriately. We obviously didn't ask it or they didn't hear the question right.
DR. MC DONALD: Weren't these sent out to you?
DR. COHN: This specific question probably wasn't.
DR. MC DONALD: The letter, I thought the letter was sent out.
AUDIENCE: When I read that it was, okay, what am I supposed to do with the RIM.
DR. COHN: I am hearing a couple of things. First of all, it sounds like we need to be encouraging the SDOs, and all the SDOs, to harmonize -- I am not sure if the right word is harmonize, but basically to participate and use the USHIK, which isn't even in here. That is issue number one.
Issue number two is that we need to encourage them to have discussions with HL7 to understand the applicability and appropriateness and value of participating in further development of the RIM, or something like that. I am not sure if that is exactly the right recommendation, but I think that is another step.
DR. MC DONALD: It depends on how bold you want to be. All the rest about -- I didn't invent anything in that paragraph, but if you really want to end up with an intercollaborative, high intercollaborative, that is the way to do it. If you want to keep everybody happy, you soften it.
DR. ZUBELDIA: This is making the RIM as the reference level for everybody.
MR. BLAIR: Here is what I might suggest, if I can find my way around here, it is going to be easier for the SDOs to share their data elements and data definitions in the meta data registry, which is the USHIK. It doesn't force them to change anything.
We might put that recommendation as a first step, is to actively contribute your information and work in a collaborative stage with the meta data registry.
Then, have a separate recommendation that we also encourage, on a longer-term basis, convergence with the HL7 reference information model, which would be born to mandate.
Now, I am sort of looking at you, Kepa, as I say this, because I carved it up into two separate stages. Clearly, the one that would have the most difficulty working with the RIM, I think, is the X12.
If we divided it into those two stages, would it make it more palatable?
DR. MC DONALD: I would take the X12 out at this stage.
DR. ZUBELDIA: They are not going to be able to change their models to converge onto the RIM. Then they have to redo all the transactions.
MR. BLAIR: Simon, so far, X12 has excluded itself within the domain of being a PMRI standard. Maybe it is hard to include them in the letter.
DR. FITZMAURICE: We could include them by inference. All standards should move toward presenting their data in a meta data registry. All standards developing organizations should converge toward a reference information model.
DR. MC DONALD: That is quite a different statement. I am not suggesting what you should say. Everyone always says that. We will be here another 100 years.
DR. COHN: We have been so far. First of all, let's just start at a very basic level. I think this whole topic here is having to do with sort of data modeling and data work to increase interoperability, I think is what we are talking about here. Obviously, this is a major topic.
Obviously, the USHIK issue is one issue. I am sorry, we keep pulling me back here to the table, but what do you feel about a recommendation that the NCPDP harmonize your data elements and data definitions with the RIM. Is that something you considered, talked to your NCPDP about, answered questions from the NCVHS in the affirmative about? What is the NCPDP's position about this?
MS. GILBERTSON: At this point, I don't have any working knowledge of the RIM, so I am not sure what I am pointed toward.
I think the answer to the question is, of course, we would be definitely willing to look into what its impact is.
DR. COHN: You are willing to investigate it?
MS. GILBERTSON: Sure, I don't see any problem with that.
DR. COHN: The reason I am asking Lynne is, we just made a comment that, geez, X12, we didn't talk to them, they weren't at the table, we shouldn't exclude them. Now, what we are hearing also is, NCPDP, although they were at the table for many of these conversations, doesn't feel like it was explicitly asked, and doesn't have a position on this either.
DR. MC DONALD: That is two different issues. I think we should leave out X12, not because I am negative about X12, but that they really don't -- in a real institutional environment it sort of works now.
They send their stuff out. The billing system is another layer. I am not denying that there aren't harmony things that could be very advantageous.
The script and HL7 are right on top of each other. They are doing the same kind of thing. I think they are collaborating two pairs of groups and they will work stuff out.
The same with DICOM. They are sending HL7 orders out and they are already sort of living together. Script isn't coming together much, but it should, if you want to do all the things you finally could do, like discharge drugs go right to the pharmacy from the hospital, and all the other things you could invent.
Really, they are right in the same cauldron. I think this paragraph makes sense for them. We are just going to get political complications because HL7 said they weren't on this kind of standard, and we are writing about this standard.
The second thing is, these letters went out a couple different times. We had testimony this morning. It wasn't a high issue then.
Either people had to say their piece when they came to testify -- it is all English. These are the same paragraphs. We haven't fiddled with it.
DR. ZUBELDIA: But I get the impression they didn't stop to read that section. This has pretty severe implications. They would have to change the way they are doing modeling today, to convert it to here.
DR. MC DONALD: I wouldn't say convert. That is very strong.
DR. ZUBELDIA: I think it is very positive.
MR. BLAIR: We were planning to take this next draft and send it out again to the SDOs and to any other interested parties to ask for additional comments.
We can, in the cover e mail, ask them to please take a look at the last paragraph, and get their reactions?
DR. YASNOFF: Jeff, I think that is a good idea. In addition, just reading this paragraph, it doesn't seem very draconian to me.
We are just encouraging people to do this. We are not saying they have to do it. We are noting certain things that are done that are good. I don't think this forces people to do anything. I mean, Kepa, why does this concern you?
DR. ZUBELDIA: I have been around X12 long enough to know what their fears are. My fear is that a recommendation like this could end up reflected in some regulation, that somehow requires X12 to drop the models that they have.
DR. YASNOFF: X12 isn't mentioned in here.
MR. BLAIR: Yes, we keep X12 out.
DR. MC DONALD: X12 isn't in this paragraph anywhere. X12 doesn't even exist.
DR. ZUBELDIA: It could affect NCPDP and have them change all of their transaction modeling to use the RIM. I don't know if NCPDP is ready to do that, but they will consider it.
DR. YASNOFF: If we encourage them to do this, they can come back and testify that they don't want to do it.
DR. ZUBELDIA: I am glad that Lynne is here, because she can take the message that this is not a draconian position.
From the X12 position, that is always the fear, that X12 is going to impose something on us.
DR. YASNOFF: This whole thing is all guidance. We are not recommending a single regulation of any kind for anybody.
MS. GILBERTSON: Are we assuming that HL7 wants it, too?
DR. ZUBELDIA: Well, it is the HL7 RIM.
MS. GILBERTSON: Are we assuming that they want to harmonize with all the other standards to the RIM?
MR. BLAIR: For the record, I think that I would say that I have not seen HL7 -- I am not aware that HL7 has put pressure on anyone else to do that.
I think they try to point out to as many people the value of a reference information model, and try to encourage people, other SDOs included, to take advantage of the value of having one single reference information model.
DR. MC DONALD: I know DICOM has been active and interested, and it is pretty flexible. The real challenge here is, here are the choices we have got.
We go, all you guys play together and we will invent something new, and nothing is going to happen.
So, we have either got to decide that we don't care about pushing anything, or we do. If we push something -- as I said, I have nothing to do with this paragraph.
This paragraph is basically a very sort of bold step, although it is gentle, in that it really says that something could happen that we would all be talking to each other in a very happy way in three to five years.
Anything short of this, even sort of bringing it out, is going to be business as usual and there will probably be divergent evolution.
MR. BLAIR: Kepa, this is our job, kind of, on NCVHS, to kind of set direction and encourage --
DR. ZUBELDIA: I agree, and I am glad that NCPDP is here today. I am in favor of this. I am not saying take it out.
MS. GILBERTSON: I thought we were going to mention X12.
MR. BLAIR: If we can. I think we have to leave X12 out.
DR. MC DONALD: X12, they said they were not one of these kinds of standards. I think it just makes it easier.
DR. COHN: Go ahead.
DR. YASNOFF: We have a paragraph to go back to.
DR. COHN: I think that there needs to be significant re-doing of this. I think we have already mentioned the USHIK piece that needs to be included.
DR. MC DONALD: When you are saying this, this paragraph or this whole thing that we just worked through?
DR. COHN: I am talking about this industry guidance paragraph, which it seems to me has changed in a relatively significant way.
DR. MC DONALD: But what?
DR. COHN: That is what I am trying to figure out, since none of this is reflected up there. I think that we have said that we need to include the issue of contributing and participating in the USHIK initiative.
DR. MC DONALD: I would like to leave the thoughts that I thought I heard. One of them, Bill says, this is not too bad and not too good. Kepa says, I am supportive of it.
I think it is a good idea. I know the drafter of it has some support for it. I don't think this needs to start from scratch unless you specifically say what we should rip out of it.
DR. COHN: So, you are in essence suggesting that we add to this, that people should also be encouraged to participate in USHIK?
DR. COHN: That is sort of step one. Step two is having to do with the RIM. I guess in my own mind I am not sure -- I guess we should maybe send letters out to the other SDOs.
DR. MC DONALD: Simon, you are saying we should rewrite this paragraph and I haven't heard it from the committee.
So, let's be specific about what you really think. We can just agree on it and get it done.
DR. ZUBELDIA: Maybe all it needs is one sentence to mention USHIK.
DR. COHN: I guess the other question is, are we really excluding X12 from the entire discussion, or do we need to just figure out some way to get X12 involved?
DR. ZUBELDIA: I think X12 has excluded itself from the entire discussion. We have been trying to include them and sent them letters and letters.
DR. FITZMAURICE: Does it make sense to send this out to X12 when we send it out to the others?
DR. COHN: Sure.
DR. ZUBELDIA: Send it to everybody for review.
DR. COHN: And ask them, should they be included in this paragraph.
DR. MC DONALD: Just say review it. They have already said they are not one of these things. They can say whatever they want.
DR. COHN: Stop, let me go back for a second. If what we are talking about is interoperability and comparability, and the only thing we are doing is making sure that we can do pharmacy and clinical care, but have no concern or care for interoperability in relationship to cost of care, billing for care, membership, enrollment, you name it, have we missed something here?
MS. GILBERTSON: Yes.
DR. COHN: Am I off?
MS. GILBERTSON: No.
DR. COHN: Is my issue about bring up X12 --
DR. MC DONALD: The question is what is realizable in the next epoch, say three to six months. They have said they are not one of these standards.
We are now making a decision about this kind of standard. We haven't done vocabulary yet either. There is a lot of important stuff to do.
If we always had to do everything each time we did anything, then we would never get anything done. I think all that will happen with that is that we won't make any statements. We will end up being very bland and won't get anywhere in this particular domain.
We have not finished all our work when we finish this, but we want to make this digestible enough so that we don't get people who said, we are not one of them, why are you dragging us in, and make the whole thing blow up. It is political rather than technical.
MR. BLAIR: What about this idea, and this would be an allusion to the subject, Simon, that you feel should at least be referenced in the letter.
I do think that this letter is bounded to specifically address PMRI message format standards. In the very very last paragraph, we mention the other topics that we would begin to look at in the future.
The other topics include medical terminologies. They include a couple of other things. What if we included to that the topic of harmonization between PMRI and reimbursement standards, if it is not there already, and that would -- as a future topic to discuss.
DR. FITZMAURICE: How about administrative standards rather than reimbursement standards?
DR. ZUBELDIA: All health care standards.
DR. FITZMAURICE: All health care standards? Does that schmooze it over?
DR. COHN: I think we may want to just ask X12 specifically, do they want to be included in this particular area also.
MR. BLAIR: I think we can. We actually have -- we invited them already. We sent them the questionnaire. We followed up with the questionnaire and they declined.
They did indicate that they discussed it. It is not like they ignored it. They declined to send in a response saying that they were a PMRI message format standard, or that they had any standards to offer.
DR. ZUBELDIA: Take this entire paragraph, move it down, and put a subtitle that would say, harmonization of standards.
Change it to say, instead of encouraging these two SDOs, it encourages all SDOs to harmonize their data elements. Just change this to make it a generic statement for all of them, by taking this whole paragraph out.
MS. BURKE-BEBEE: That still doesn't include X12 because they are never mentioned. We are assuming that X12 buys into harmonization with clinical standards.
I don't know, having attended both, that X12 buys into that. Isn't that something that we are trying to accomplish?
I agree with you, though, Clem, that there is a time, and this letter isn't the time. I agree with you, Simon, that it needs to be done, but I don't think this is the time.
DR. MC DONALD: I think if we try to get too many people to agree, it just reduces the chances. They are drowning right now in all this other stuff.
The truth is, it is pretty easy to link up with registration data. You can do that lots of ways. The codes are more dominant in the problems that we have.
MR. BLAIR: I think that if we leave the paragraph that we have been working on, to just adding the USHIK phrase to that, and then adding to the final paragraph where we are saying we are looking into the future, that we will also be looking at the harmonization with financial and administrative data.
DR. ZUBELDIA: One of the issues is that we have this -- this is the structure of the document. We have this section called standards for specific PMRI market segments.
Under that, we have DICOM and NCPDP. We have a recommendation and industry guidance to adopt the latest version. Then we have this harmonization paragraph. It needs another header.
MS. BURKE-BEBEE: One of the things I have looked at, too, now that we have done all the work that we have done, I am trying to find out, where are the recommendations and what are they.
There is no consistency in their presentation in this letter. When you start, on the second page, there is a recommendation, when you look at the second page, there are actually six recommendations, but they are all in text. What I mean by that, there are no bullets, that type of thing.
When you go to the next page, which is page three, although it is not marked, you then have three more. I am wondering if the format needs to be worked on, maybe not at this point, but that concerns me.
If I was the secretary and I was looking at this, our previous report was very spelled out, number one, number two, number three.
DR. COHN: This is still a draft. I agree with you, it does need a fair amount of formatting. I am recognizing that we still have a couple of months. I think we are trying to get the basic information down at this point.
So, I agree with you. Hopefully, you will help us with some of that work and all that. I am sure that the whole subcommittee recognizes that we will be looking at this probably again in February, and hopefully that will all be done before then. I absolutely agree. I am sure the rest of the committee does, too. So, we made that change.
DR. ZUBELDIA: I made that change. Can you read the whole thing?
DR. COHN: Do you want me to read this for you?
MR. BLAIR: Please.
DR. COHN: Okay. It says, NCVHS encourages the SDOs to harmonize through data elements and their data definitions for future versions, so they are consistent with the HL7 reference information model.
Additionally, NCVHS encourages the SDOs to continue their collaboration to reduce or eliminate duplication or inconsistent data elements, especially those for patient information.
NCVHS also encourages the ongoing collaboration among the SDOs to harmonize the data elements within existing versions of their standards. I think we still need some work here.
DR. BURKE-BEBEE: We are getting there.
DR. ZUBELDIA: It is very redundant.
MS. BURKE-BEBEE: Yes, it is.
DR. YASNOFF: In the first sentence you could say, existing and future versions, and then you could get rid of the last sentence, I think.
Now it says, NCVHS encourages the SDOs to harmonize their data elements -- get rid of the second their -- data elements and data definitions for existing and future versions, so they are consistent with the HL7 information model, RIM.
Additionally, NCVHS encourages the SDOs to continue their collaboration to reduce or eliminate duplicate or inconsistent data elements, especially those for patient information.
In other words, everyone should play nicely together around the RIM.
DR. MC DONALD: That may be stronger than it will be easy to politically accept. I don't think I would say existing and future. Existing is very hard. That is for the first paragraph. Now, you could say that about the second thought.
MR. BLAIR: You said both those things.
DR. MC DONALD: Not for the reference model.
MR. BLAIR: What I would suggest is that, in terms of current collaboration, we do the USHIK, because that doesn't require any changes, and that for the future we encourage coordination with the RIM.
DR. YASNOFF: So, get rid of existing and.
MS. BURKE-BEBEE: So, do you need to add a sentence there, like Jeff said?
DR. MC DONALD: That would be perfect, and we would get that thought again, for the present and the future.
DR. YASNOFF: You could just put in a note in the beginning, just put in brackets, participation in USHIK, and somebody will write a sentence later.
MR. BLAIR: That is the current.
DR. COHN: Could you repeat that sentence, Jeff?
MR. BLAIR: I would say, NCVHS encourages the SDOs to share their data elements and data definitions with the U.S. Health Information Knowledgebase, and then put in parenthesis after that, meta data registry. That would be like one sentence.
Then the next sentence would wind up saying, furthermore -- am I going too fast?
DR. ZUBELDIA: I haven't even started yet.
DR. COHN: Mike has got that.
MR. BLAIR: Then I would say, furthermore, the NCVHS encourages all PMRI SDOs to collaborate together -- how do I want to say this -- to collaborate together to harmonize their data elements to the HL7 reference information model.
DR. YASNOFF: But do you want to say for future versions? It already says that. It says, encourages SDOs to harmonize their data elements and data definitions for future versions, so that they are consistent with the HL7 reference information. I think that is okay.
DR. ZUBELDIA: Mike, do you want to give me what you had on the first one?
DR. FITZMAURICE: NCVHS encourages the PMRI SDOs to share their data elements and data definitions with the U.S. Health Information Knowledgebase -- parenthesis, meta data registry.
MS. BURKE-BEBEE: Knowledgebase is all one word.
DR. COHN: Time to save the document again. Do we need to reread it now? Okay. The NCVHS encourages the PMRI SDOs to share their data elements and data definitions with USHIK.
Furthermore, NCVHS encourages the SDOs to harmonize their data elements and data definitions for future version so they are consistent with the HL7 reference information model.
Additionally, NCVHS encourages the SDOs to continue their collaboration to reduce or eliminate duplicate or inconsistent data elements, especially those for patient information.
NCVHS also encourages --
MR. BLAIR: I think we could delete that one. The first two sentences kind of have it, don't they?
DR. COHN: I think so. The last sentence is very redundant with everything else. Should we get rid of the last sentence?
Additionally, the NCVHS encourages the SDOs to continue their collaboration to reduce or eliminate duplication or inconsistent data elements, especially those for patient information, and NCVHS also encourages the ongoing collaboration among the SDOs to harmonize the data elements with existing versions of their standards? I think that last two sentences could be deleted.
DR. MC DONALD: Not two, there is a different thought. One, you are saying, sharing the data elements. That is easy. It doesn't make anything happen.
The second one is a little harder, and it may not happen because it is too hard. The third one is yet a different level. I think it is a different concept.
DR. COHN: What about the fourth one?
DR. MC DONALD: The Script and HL7 could get together and make sure they are lined up just on segments. That still would be good.
DR. COHN: If you are going to keep all these, shouldn't they be in a different order?
DR. MC DONALD: There are too many sentences in here. Of the last two, one of them could say. I think it is the third one, the last of the first two.
DR. ZUBELDIA: This additionally?
DR. MC DONALD: Keep that one and get rid of the last sentence. You might want to put them in a different order.
DR. YASNOFF: You might want to put the RIM last, since that is the hardest thing.
DR. ZUBELDIA: So, the additionally goes before the furthermore?
DR. COHN: Yes.
MR. BLAIR: Clem, could I have your guidance on this a little bit? Is the harmonization of the SDOs relative to the RIM only limited to data elements and data definitions or is it also going to be within context, or is that going to be where they divide?
DR. MC DONALD: I think it sounds okay. I think if we try to be too specific and too directive, we might make it harder.
AUDIENCE: I just wonder if it is worth recommending to HHS that there might be some funding that could happen in this area, since all the SDOs said voluntary work was hard to do right now.
DR. MC DONALD: Funding for all of this collaboration? It is the thing that gets cut out when everybody is at the top.
DR. COHN: So, add a sentence in here, NCVHS recommends that HHS provide some incentives?
DR. MC DONALD: What they need is some extra dollars to pay people to do some of this collaborating work. I don't know how you do that.
What you want to do is pay some consultants who would do some extra time.
DR. ZUBELDIA: So, we end up with three thoughts in this paragraph.
DR. COHN: Right, and then a final -- I think there is an NCVHS recommendation for funding. I think that is at the end.
MS. BURKE-BEBEE: Recommends funding of PMRI SDO collaborative efforts?
DR. COHN: Promotes harmonization.
MS. BURKE-BEBEE: Just as a place holder. HHS funding of PMRI SDO collaborative efforts and whatever Simon said, harmonization.
DR. COHN: Let's go on to the next paragraph. Then we will go back to the work Bill has done, and then hopefully we will adjourn, as an incentive out there in the future.
So, next paragraph, the NCVHS has limited its first set of PMRI recommendations to message format standards.
The committee plans to begin investigating medical terminologies and code sets for the first half of 2002. The committee will also consider PMRI standards for clinical documents, and the content and structure of patient records in the future.
A couple of word smithing issues. I would say -- I am not sure. Is this the first set of PMRI recommendations? I thought this was the second set.
MR. BLAIR: It is the first set of specific PMRI recommendations.
DR. COHN: So, it is the second set of recommendations.
MR. BLAIR: I think that would be confusing in the sense that the document we gave them --
DR. COHN: How about, has limited these PMRI recommendations.
DR. FITZMAURICE: The PMRI-specific.
DR. COHN: We had a 40-page document that we gave them.
DR. FITZMAURICE: These are standard specific.
MR. BLAIR: It was the framework and guiding principles. It indicated that our first phase of specific recommendations would be this.
DR. COHN: Let's see what Kepa is coming up with here. The NCVHS has limited these PMRI-specific recommendations to message format standards? Okay.
Now, next sentence, the committee plans to begin investigating. I think we have already been investigating medical terminologies and code sets. I think we should say, will be further investigating.
DR. ZUBELDIA: Continue to further?
DR. COHN: Plans to further investigate medical terminologies and code sets?
DR. FITZMAURICE: I wouldn't limit it to the first half of 2002.
DR. COHN: I am not even sure we are going to get there in the first half of 2002.
MS. BURKE-BEBEE: We will get there in 2002, though, won't we?
DR. COHN: The committee plans to further investigate medical terminologies and code sets, and will be forwarding recommendations to you?
DR. FITZMAURICE: You might say something like, beginning in 2002. Just add some structure. We start here on this, and stop. What we actually do is kind of continuous.
DR. COHN: So, how about this. The committee plans to further investigate medical terminologies and code sets in 2002, and will be forwarding recommendations to you?
DR. FITZMAURICE: In the future, the committee will consider PMRI standards for clinical documents and the content and structure of patient records. That kind of separates things in time.
Here is what we are going to be doing in the beginning of 2002, and in the future, here is what we are going to do.
DR. COHN: I guess maybe we will reflect on this as we talk about the plans for 2002, given tomorrow's conversation. Is that how we want to phrase that, since our agenda has gotten added to?
Now, we need to go back and fix that -- I am not entirely satisfied with this, but it is not bad.
The NCVHS wishes to thank the Secretary for the opportunity to submit these recommendations within the framework of the administrative simplification provisions of HIPAA.
DR. ZUBELDIA: Okay, what do we want to do with IEEE?
DR. YASNOFF: That is going to be decided later, I thought. There are going to be some e mails exchanged?
DR. ZUBELDIA: So, I just take it out of here?
DR. COHN: Leave it there for the moment.
DR. YASNOFF: Leave it as a reminder.
MR. BLAIR: Could I suggest that, in terms of what we are going to look at in the future, that we include everything in that list, that gives us the flexibility that if we want to change the sequence of what we look at, that we have the flexibility.
So, we don't imply that we are going to have recommendations in medical terminologies and that will be followed by CDA afterwards? Could we just leave that all in one grouping, that we are going to be looking further at all these other topics?
DR. ZUBELDIA: We can take out the in the future and say, the committee will also consider PMRI standards for clinical documents and the content and structure of patient records. We don't say it would be before and after.
DR. COHN: The question is whether we will be forwarding recommendations on medical terminologies and code sets.
MR. BLAIR: Did we want to include in this area a reference to us examining harmonization between PMRI standards and the administrative transactions or not?
DR. FITZMAURICE: I would be inclined not to muddy the water too much and throw fear into X12.
DR. COHN: Okay, anybody else? I think that is fine.
DR. ZUBELDIA: Okay, I want to save this.
DR. COHN: I am just looking at, we will be forwarding recommendations. Maybe we can soften that one up a little bit.
DR. ZUBELDIA: Do you want to take a look at it here?
DR. YASNOFF: No, scroll down, and let's go to the one that -- I put it in twice. Okay, here is what I wrote. Once again, this section is just to remind you and get you back to that section.
The second is recognition of current standards and incentives for emerging standards. The NCVHS has recognized the important role played by the PMRI standards currently used by the health care industry.
Since it has taken years for today's standards to achieve broad market acceptance, they are based on older conceptual models.
These models do not uniformly provide the high degree of interoperability and data comparability that are necessary to support significant improvements in health care costs, quality and productivity.
To promote more rapid realization of these benefits in accordance with the prior recommendations in the PMRI report, NCVHS is recommending that HHS both recognize current standards and provide specific incentives to accelerate the development and early adoption of more advanced PMRI standards.
MR. BLAIR: I love it.
DR. YASNOFF: Okay, there is an error, and that is the high degree that is necessary. It is grammatically incorrect. High degree is necessary. Are should be is.
DR. MC DONALD: I like most of your writing, but I found one. You say, to support significant improvements. It is true, that we are interesting in improving. So, you can go right to that.
You can say necessary to improve health care quality and costs, or maximally improve.
DR. YASNOFF: Actually, improving health care costs.
DR. MC DONALD: Yes, that would have to be fixed. You are really sort of saying support significant improvements in. Strunk and White wouldn't like that.
DR. YASNOFF: Why don't you just take this and copy it.
DR. COHN: Very good, thank you.
MR. BLAIR: I am assuming that, following that, there is some statement about the fact that we are asking for HHS incentive to accelerate the development and implementation of emerging --
DR. YASNOFF: It says that right in that paragraph. That is that last sentence, the last clause. NCVHS is recommending that HHS both recognize current standards and provide specific incentives to accelerate the development and early adoption of more advanced PMRI standards.
MR. BLAIR: Where you say more advanced, I think we need to key it in the letter. We refer to those as emerging.
DR. YASNOFF: Do you want to use the word emerging? That is fine.
MR. BLAIR: In there somewhere, yes.
DR. YASNOFF: Essentially, this paragraph is an introductory summary to what we are going to say later, is what it was trying to be, but it was confusing.
MR. BLAIR: Are we going to replace more advanced with emerging?
DR. YASNOFF: Yes, we can replace more advanced with emerging.
DR. ZUBELDIA: So, all of this goes.
DR. YASNOFF: All of that goes, and replace more advanced with emerging.
DR. FITZMAURICE: Everywhere it comes up or just in that paragraph?
MR. BLAIR: Just in that sentence.
DR. YASNOFF: Right there in that last line, second to last line, where it says more advanced. At the end of that line where it says more advanced. Put emerging.
DR. FITZMAURICE: I thought you were doing just the opposite.
DR. COHN: As I said, this is not the last -- unfortunately or maybe fortunately -- this is not the last time we look at this.
I think we have a couple of to do items around IEEE and we will, I think, probably mull over the model issue and all of that a little more as we go forward.
I think we have made major improvements and thank you all. This is mighty expensive word smithing, and yet, the documents we have produced have been excellent and I think sometimes have changed government policy, or at least approaches. I think all the energy we put in is a value we need to acknowledge.
DR. YASNOFF: I am confident that the Secretary analyzes our documents in as great detail as we do.
DR. FITZMAURICE: I hope it is, because it comes right back to you and me.
DR. YASNOFF: That is right, the documents are sent for comment.
DR. COHN: I think one should also acknowledge that maybe the Secretary and staff are not the only ones who actually read our letters.
One of the things we are looking at tomorrow is some legislation that has been passed recently related to a delay for administrative and financial transaction that appear to at least have been informed by our letter of late June.
I just wanted to alert you all, that what is on your desks is a copy of the passed version of the House Resolution 3323, which as you know, was also passed by the Senate.
DR. ZUBELDIA: Passed by the Senate yesterday afternoon.
DR. COHN: They adopted it, which obviously significantly increases the likelihood that such a thing will be signed into law.
DR. FITZMAURICE: It is authorization. It is not appropriation.
DR. COHN: Jeff, I should allow you to wrap up for the day. I just want to alert all of you that you should all try to read this over this evening. We will obviously be discussing it, since the NCVHS is named to do a number of activities.
At least as I read earlier versions of this, it is clear that the Subcommittee on Standards and Security will have major responsibility within the NCVHS for many of these activities.
Part of our discussion tomorrow will be how we organize and what it is that we need to do to helping industry be successful with implementation.
With that, Jeff, would you like to make any final comments and we will adjourn?
MR. BLAIR: Let me just do a couple little clarifications. Kepa, will you be sending this revised version to the subcommittee as a whole?
DR. ZUBELDIA: I am going to give it to Maria right now on a floppy.
MR. BLAIR: Okay, and then she can send it to all of us. I guess then Michael and I will get an e mail note to Todd Cooper for additional information, hopefully, next week.
DR. FITZMAURICE: I will draft that letter and let you look it over before we send it.
MR. BLAIR: Great. Then the other to do that I believe that I have, Simon, is that once this letter, this draft, gets to my e mail, I could distribute it to the SDOs for additional comment, and to other interested parties. Is that consistent with your thoughts?
DR. COHN: Sure.
MR. BLAIR: If there is anybody on the subcommittee or staff that wants to give me or Michael the names of other interested parties that you would like to have review this draft, please let me know.
DR. FITZMAURICE: Jeff, I might suggest that you take the time, before you send it out to the other SDOs, just to read through it for consistency of thought, that it says what you want it to say.
MR. BLAIR: Thank you, Michael. That is about all I have. Simon, thank you.
DR. COHN: Thank you. With that, we will adjourn and we will reconvene at 8:30 tomorrow morning.
[Whereupon, at 5:35 p.m., the meeting was recessed, to reconvene the following day, Friday, December 14, 2001.]