Room 505A
Hubert H. Humphrey Building
200
Independence Avenue, S.W.
Washington, D.C. 20201
Jeffrey S. Blair, M.B.A.
Simon P. Cohn, M.D.
Kathryn L.
Coltin, M.P.H.
Kathleen A. Frawley, J.D.
Daniel Friedman, Ph.D.
Kathleen Fyffe, M.H.A.
Robert M. Gellman, J.D.
John R.
Lumpkin, M.D.
Clement Joseph McDonald, M.D.
Barbara Starfield,
M.D.
George H. Van Amburg, M.P.H.
James Scanlon, HHS Executive Staff Director
Marjorie S. Greenberg,
Executive Secretary
Judy Ball
William Braithwaite
Karen
Trudel
Call to Order, Introductions - John Lumpkin
Review Revised Charge of Subcommittee
Preliminary Electronic Medical Record Workplan - Jeff Blair, Simon Cohn
Issues: Scope of NCVHS Activity on CPR, Structure of Workgroup, Fit, Staffing
Review Potential Comments on Two Notices Proposed Rule Making Now Open for Public Comment:
Issue: Discuss Coordinated Timing of Final Compliance Dates
Preliminary Steps Toward Development of a Framework for Procedure Classification Systems
Issues: Data Control, Ownership, Access
Standardizing Claims Attachments
Issues: Effect of HCFA Stop-Work Order, ASCII Alternative to HL7 Messages
Issues: Questions, Witness List
Agenda Item: Call to Order, Introductions
DR. LUMPKIN: Good morning. My name is John Lumpkin and I am chair of the Work Group on Administrative Simplification of the Subcommittee on -- anyway, the National Committee on Vital and Health Statistics -- right, but that name may change tomorrow. So, that is the reason why I can't remember it. It is like one of those things.
But I would like to start off the meeting. For everyone's information, we will be going out on the Internet and I am hoping that other experience would be much better than when I tried to listen to meaning on the Internet and maybe my modem was just slow, but I timed out a lot, but I think a lot of other people with bigger pipes are able to listen.
What I was going to say is make sure that everyone speak up and talk close to the microphone so that everyone else out there can hear. That also means that when we have people speak that there are microphones in the front that we will ask people to utilize.
This is a meeting of the work group and as such, it is open to the public, but because of the extent of the content, we do have scheduled speakers, we will -- depending upon the time frames, we may be able to accept comments from the audience, but those will be very limited.
I would like to start off with introductions and we are going to ask everyone to introduce themselves so that people listening in can at least try to identify with the voices. And I will start with Judy.
MS. BALL: Judy Ball from HHS. I am staff to the subcommittee.
MR. SCANLON: I am Jim Scanlon, also from HHS. I am the executive staff director of the National Committee.
DR. MC DONALD: Clem McDonald from the Regenstrief Institute, Indiana University and I am a member of the committee.
DR. COHN: Simon Cohn, Kaiser Permanente Medical Care Program and a member of the committee.
MR. BLAIR: Jeff Blair, Medical Records Institute, a member of the committee.
MS. FRAWLEY: Kathleen Frawley, the American Health Information Management Association, member of the committee.
MS. COLTIN: Kathryn Coltin, Harvard Pilgrim Health Care, a member of the committee.
MR. BRAITHWAITE: Bill Braithwaite, HHS, staff to the subcommittee.
MS. TRUDEL: Karen Trudel, HHS, staff to the subcommittee.
MS. FYFFE: Kathleen Fyffe, as the other Kathleens, born in the 1960s, Health Insurance Association of America and a member on the committee.
DR. LUMPKIN: Okay. Let's start all the way over there.
[Further introductions off microphone.]
Agenda Item: Review Revised Charge of Subcommittee
We have as our first action in the recommended reorganization of the committees of the NCVHS, of the subcommittees, the new name of this group being would be the Subcommittee on Standards and Security. And we have a charge in front of us. Is there any discussion on the charge?
MR. BLAIR: For my benefit, if it is just a sentence or two, could you read it for me?
DR. LUMPKIN: It is a little bit longer, but I will read it for you because I don't think we have all seen it and those on the Internet may not have seen it either.
[Multiple discussions.]
The charge: The subcommittee will monitor and make recommendations to the full committee on health data standards and security, primarily related to the implementation of the administrative simplification provisions of Public Law 104-191, fondly known as HIPAA, and other related legislation.
Specifically, the subcommittee will, one, identify opportunities and issues in health data standards and security for full committee attention.
Two, through a variety of mechanisms, to provide outreach, liaison and consultation with and serve as a forum for consumer groups, the health industry, standards development organizations, the research community and state and local governments on health data standards and security.
Three, advise the full committee on strategies, including public information, education efforts, research and development to promote a continuing process of developing and implementing standards.
Four, based upon consultation and analysis, make recommendations to the full committee on the implementation of the provisions related to health data standards outlined in PL104-191, with special attention to the standards relating to administrative transactions, electronic data interchange standards, unique health identifiers for plans, providers, employers and individuals, code sets and classification schemes, security and electronic signatures in the computerized patient record.
Five, consider the implications of and make recommendations to the full committee on the impact of standards for electronic transactions, identifiers and security on various players in the health care system, including large and small providers, large and small health plans, employers, individuals and federal, state and local government.
Provide recommendations for the full committee's annual report to Congress on the implementation of administrative simplification.
Any comments on the charge?
MR. BLAIR: From now on I am assuming because the law would up saying that the NCVHS was responsible for studying the issues related to uniform data standards for patient medical record information and -- do I understand that from now on, we will be referring to that as either computer-based patient records or computerized patient records instead of patient medical record information?
DR. MC DONALD: I think the twist he is suggesting is actually a good suggestion for modification.
Why don't you say it again?
MR. BLAIR: You mean, the actual words from the law?
DR. MC DONALD: What you just said?
MR. BLAIR: There goes a measure of my memory.
DR. MC DONALD: The last thing, talking the computerized patient record versus what you said, standards for implementing clinical patient data, I think is really --
MR. BLAIR: I was repeating the words from the law.
DR. LUMPKIN: What did that law say?
MR. BLAIR: I think the words were -- and I don't have a perfect memory, so, if somebody has got a copy here, you know, correct me, but I think it is pretty close to the NCVHS will study the issues related to uniform data standards for patient medical record information and the electronic exchange of that information.
I would have no vested interest in one way or another, but I just noticed the change and I don't know if there is an importance or significance to that. In which case, maybe we should all be consistent with using computer-based patient records or computerized patient records or do we need to stay with the words in the law?
DR. MC DONALD: I think the emphasis on the computer system is mistargeted. That is, when you say computers, you think about the box; whereas, as the legislation is stated, it emphasizes the data and I think that is --
MR. BLAIR: Yes, it does say data, data standards, uniform data standards.
MS. FYFFE: Actually, I have a copy of the law here.
DR. LUMPKIN: Oh, good.
MR. BLAIR: And it says?
MS. FYFFE: In complying with the requirements imposed on the Secretary under Part C of Title XI of the Social Security Act, shall study the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of such information, shall report to the Secretary not later than four years after the date of the enactment of HIPAA recommendations and legislation proposals for such standards and electronic exchange and shall be responsible generally for advising the Secretary and the Congress on the status of the implementation of Part C of Title XI of the Social Security Act.
DR. LUMPKIN: So, the term that is used exactly is patient record medical --
MS. FYFFE: Yes. Adoption of uniform data standards for patient medical record information and the electronic exchange of such information.
DR. LUMPKIN: Am I hearing a desire to paraphrase the law for that charge instead of computerized patient -- Simon?
DR. COHN: Actually, I was going to speak against that, but it needs to come on the floor first. Did you want to --
DR. MC DONALD: Yes. You know, we have too long focused on the box and the machinery and the system rather than on the content and it hasn't gotten us as far as we can if we focus on the content.
DR. LUMPKIN: Okay. So, we have a motion to substitute where we have used computer-based patient records or something to that effect -- patient computerized record, to replace it with that phrase --
MS. FYFFE: Which is "patient medical record information and the electronic exchange of such information."
DR. LUMPKIN: Wasn't there a clause right before that?
MR. BLAIR: Uniform data standards for.
DR. LUMPKIN: Okay. I think we need that. Uniform data standards for --
MS. FYFFE: Right.
DR. LUMPKIN: I assume that since, Jeff, you first raised it, you second that motion to get it on the floor?
MR. BLAIR: Why not. I second that motion.
DR. COHN: I think my only comment -- and I am well aware of that piece of the legislation. It actually was quoted in a charge for a work group. Having said that, I do question whether the charge of the subcommittee needs to quote or absolutely mirror the HIPAA legislation. I think that what we are talking about is really a subset of really computer-based patient record standards, at least as far as I am concerned and it may be that the committee at times wishes to expand the scope beyond just HIPAA regulations. So, that would be the only concern I would have with limiting it just to the language of the legislation.
DR. LUMPKIN: Let me see if I can clarify because I think the issue that I heard is whether or not computerized patient record limits us and the HIPAA language expands us and I think that is what I hear is the issue of contention. You would interpret that as being -- the HIPAA language being more restrictive. Okay.
Anyone else want to weigh in on that?
DR. COHN: Perhaps we need to add both then. Maybe we need to have that wording and the computer-based patient record. If the issue is which is more limiting and there seems to be some differences of --
DR. LUMPKIN: You are suggesting or -- could we live with that language and then going -- including the computerized patient record?
DR. COHN: Let's see how it would read. I guess the adoption of uniform data standards for patient medical record information, electronic exchange of such information and the computer-based patient record and that would --
DR. LUMPKIN: Marjorie.
MS. GREENBERG: I feel like I came sort of in the middle of this discussion, but kind of in support of what Simon just said, I just thought I would contribute that when at one point in developing various memoranda to the Data Council about the new structure of the committee, we had referred to a work group on electronic medical records and Don Detmer, our chair, was very definite that he wanted that referred to as computer-based patient records.
So, I can't speak for him today, but I know that we changed our terminology in response to his request.
DR. MC DONALD: Well, to move it along, if we could accept his amendment and the seconder, to add in computerized -- whatever --
DR. LUMPKIN: Probably instead of "and," why don't we say "including"?
DR. MC DONALD: Sounds good.
DR. LUMPKIN: Okay. We have language, I think --
Anybody have it, who could read it in its entirety?
MR. BLAIR: Can I make a comment about this? It is in support of doing both. My feeling is that I thought I perceived some wisdom in the phrasing of uniform data standards for patient medical record information and the exchange of that information in the sense that as opposed to winding up identifying it as a system or a technology or a method or a solution, those words to me meant the data standards that would facilitate the evolution towards a health care information infrastructure, and this is a critical area that is need to do that, and -- now, I am not sure that that was the intent of the authors, but that is, at least, what I was reading into it.
So, I thought that that is a very important phraseology. I have been involved with computer-based patient record systems and the CPRI for a long time. So, I feel perfectly comfortable if we wind up saying "including community-based patient record systems." I think that adds a different -- I think that does add a systems or approach solution to this, which is fine with me.
DR. LUMPKIN: Okay. Obviously, Congress had a very gifted staff to help them develop that language. So, Bill, could you read what we have come up with on our charge.
MR. BRAITHWAITE: Number 4 now reads, "Based upon consultation and analysis, make recommendations to the full committee on the implementation of the provisions relating to health data standards outlined in Public Law 104-191, with special attention to the standards relating to administrative transactions and electronic data interchange standards, unique health identifiers for plans, providers, employers and individuals, code sets and classification systems and electronic signatures and uniform data standards for patient medical record information and electronic exchange of such information, including computer-based patient record systems.
DR. LUMPKIN: All those in favor of that new language signify by saying "aye."
[There was a chorus of "ayes."]
Opposed?
[There was no response.]
Carries.
Any other comments on the document?
[There was no response.]
Okay. All those in favor of recommending adoption of this revised charge for the subcommittee to the full committee signify by saying "aye."
[There was a chorus of "ayes.]
Opposed?
[There was no response.]
We will carry forward.
Agenda Item: Preliminary Electronic Medical Record Workplan
The next item on the agenda, the preliminary computerized patient record work plan.
Simon.
DR. COHN: Okay. Well, why don't I start with a few comments. I think this is really a discussion that focuses on really the introduction of a work group on computer-based patient records.
Yes?
DR. LUMPKIN: Let me just kind of -- we will have -- when are we going to do that on the GCTR?
DR. COHN: We will do it as part of this.
DR. LUMPKIN: Okay. You will do this as part of that and you will get some introduction for the other.
Never mind.
DR. COHN: That is okay.
This is sort of an introduction to the work group. Obviously, we don't have the committee agreement yet on the changes in what should happen with charges and we are all the subcommittees and renaming, but I think there really is the presumption that a work group on computer-based patient records will be formed and we actually wanted to get started by the discussion today.
Jeff and I have been asked to lead this work group. I want to thank Jeff for his great work getting things started by developing at least a first draft of an EMR workplan, maybe a computer-based record workplan, figure out the right term for that.
I think as we have known since the -- at least since I came on the committee almost two years ago that there was going to be a need to get involved in this area. I think we all recognized that the administrative simplification provisions, especially administrative and financial transaction standards need to occur first.
Now, as we begin to finish that piece off, it really becomes time for a work group to begin to address those issues.
Now, I guess what I wanted to do is to do a couple of things. I mean, one is to invite membership from the subcommittee and from others on the NCVHS in this work group and hope that you will join, hopefully much the way the previous work group on standards functioned.
For this discussion, I think there is a number of objectives that we have. Number one is to discuss a charge for that work group and potentially if we can -- if it is good enough, wordsmith it and otherwise try to reach agreement on that today. Jeff and I also felt it was important to begin a discussion on scope of deliverables.
To me that is really the first piece of business around a workplan is to make sure that we have the right target and we need to look at the reason behind the scope of deliverables, understand them a little better, I think, discuss them among ourselves.
If, indeed, they are to a point where we can agree on them, so be it. Otherwise, we need to take the input of the subcommittee and try to create a revision that, hopefully, will be good enough that it can be approved by the committee on Wednesday. And it may not be that the full committee approves of the scope and deliverables but approves of them in a draft form that can be sent out for secondary validation, which is certainly one of the things that I would hope for by our adjournment on Wednesday.
We will also, I think, over the next hour and a half or so hear from Rob Kolodner and GCPR in relation to what they are doing around CPR and standards, to look and see if there are some opportunities for that.
Am I missing -- am I fading out here? I guess I do have to speak close to this also.
As commented, I think the process, just to reiterate, is to discuss and get input today, see if we can approve the charter; otherwise, look at the scope and deliverables and try to develop our sort of next steps for how we need to deal with that so that we can take it to the committee on Wednesday.
Why don't we at this point -- and do you have any questions so far before we just talk about the charge document, which I think everybody, except for Marjorie, has at the table? We have a charge document for the work group. But before that, are there any basic questions around the -- yes?
[Multiple discussions.]
So, no questions about the establishment of a work group on this topic?
Yes, Jeff, I will read the charge, though I don't think I do it quite as well as some others here.
The draft charge is for what we believe to be the Subcommittee on Standards and Security Work Group on Computer-Based Patient Records. It starts out with a quote of the piece of legislation that we were just referencing. It says, "Section 263 of Public Law 104-191 requires that the NCVHS (b) shall study the issues related to the adoption of uniform data standards for patient medical record information and the electronic exchange of such information and (c) shall report to the Secretary no later than four years after the date of the enactment of the Health Insurance Portability and Accountability Act of 1996, recommendations and legislative proposals for such standards and electronic exchange.
"Meeting these requirements will be a primary focus for this work group. Specifically the work group will (1) develop and initiate a workplan to assure that the committee is able to respond appropriately and in a timely fashion to the legislative requirements; (2) identify opportunities and issues for subcommittee and full committee attention; (3) through a variety of mechanisms, provide outreach, liaison in consultation with and serve as a forum for the public, consumer groups, the health industry, standard development organizations, the research community and state and local governments.
"Then, finally, (4), based upon public hearings, consultation and analysis, develop recommendations to the Department and legislative proposals for subcommittee and full committee consideration to promote the adoption of uniform data standards for patient medical record information and the electronic exchange of such information."
Anyway, that is the draft charge that we are proposing. Discussion?
DR. MC DONALD: Just a tiny change. When you specify people such -- serve as a forum of variety of people, I think we should add "and other interested parties," because you will never -- this probably doesn't subsume everyone.
DR. LUMPKIN: Which number?
DR. MC DONALD: Item 3. It is at the end, "and other interested parties," because, indeed, that is what we will do.
DR. COHN: Other comments?
DR. LUMPKIN: Jeff?
MR. BLAIR: Is it too fast for me to make a motion that the charge be accepted?
DR. MC DONALD: Second.
DR. LUMPKIN: Moved and seconded. Further discussion?
MS. GREENBERG: Basically, I think it is fine and certainly follows the legislation. I am just interested in maybe subsequently discussing what it entails for this subcommittee to develop legislative proposals because I don't think the National Committee has ever actually developed legislative proposals before.
Perhaps, our esteemed staff member, who also was involved in writing this legislation can shed a little light on that because it may not -- there may be a whole range of legislative proposals and this would be at the more general end.
MR. BRAITHWAITE: A legislative proposal does not necessarily mean writing legislation. It just means laying out what should be included in legislation and suggesting it.
MS. GREENBERG: Okay. So, it is open to broad interpretation.
MR. BRAITHWAITE: We can handle that.
MS. GREENBERG: Okay. Good.
MS. COLTIN: I have a question about whether the term "patient medical record information" and then saying the "electronic exchange of such information" is limiting in a way that -- let me just give you an example. For instance, if, in fact, there is an entry being made into an electronic medical record, an order entry, for example, and that order entry could interact with a guideline, decision guideline, or some other sort of decision support, would that be covered under this in terms of that exchange of information back or an alert from a pharmacy about a drug interaction, for example, would that be covered? Or are you talking only about the information that is in an individual's medical record as opposed to its relationship to other clinical information?
MR. BLAIR: I agree that that decision support, infrastructure issues need to be included, that they are very relevant and I hung on the words in the law, issues related to uniform data standards. I thought that word "issues related" gave us the cover to include such issues, such as decision support, problem knowledge couplers, data quality standards. So, I think it is broad enough to cover that. I hope so because I think that needs to be included.
MS. FYFFE: Does the language, "adoption of uniform data standards for medical record information," imply whether it is electronic or on paper?
MR. BLAIR: Could we go back to Bill and see what his intent was?
MS. FYFFE: Because you can have data on paper and -- well, please.
MR. BRAITHWAITE: Well, clearly, if you are going to set standards for electronically exchanging this kind of information, there are certain parts of those standards that have to carry over to the paper or it is meaningless, such as the data content. If you specify a certain set of alternatives for a particular concept and it is not on the paper, then you can't exchange it electronically, according to the standards. So, there is some implication for the paper record. But the intent, of course, was only to get into the paper as far as required in order to make the electronic exchange and electronic patient record standards workable.
MS. FYFFE: In theory, over the long run, long run, I am going to overstate my case here, everything can be exchanged electronically. So, it would be foolish not to have a standard for the paper so that eventually when that history wants to be made electronic, it can be uniform.
DR. LUMPKIN: I agree with you in theory, but I think we have to look at the reality of the system. When Dr. Weede(?) and his system of charting was developed of medical record, there was a transition of how physicians charted. There are probably still physicians who don't utilize that sort of methodology on paper records. I think that we probably ought to look for the low hanging fruit and the biggest bang for the buck and recognize that as we move forward looking at standardized ways of abstracting from natural medical language into coding systems that it will, of course, modify how clinicians of all sorts of documents -- and that documentation will become much more structured over a period of time and I think it is better to allow that to occur naturally than to try to force it.
MS. FYFFE: Okay. Just one more comment. I think --
DR. LUMPKIN: And I am just speaking --
[Multiple discussions.]
MS. FYFFE: One more comment. I think we need to keep in mind that patient medical record information can be created by a broad variety of providers. So, we are not just talking about physicians. We are talking about home health care providers, et cetera. I think we just have to be careful in what our intent is.
DR. LUMPKIN: Which is why I used the term "clinician."
DR. COHN: I think we agree and, obviously, what we are trying to do is to mirror the intent, you know, the wording of the law to allow whatever ambiguity to get that clarified on the scope and deliverables, I think, is my thought.
I was sitting back here talking a little bit only -- I was just reflecting on Kathy's earlier concern that we said, well, gee, we hope it gets covered when it gets here, but I was not quite sure whether it really was and just to go back to your earlier concern, I am actually wondering whether the last bullet -- I was talking to Dr. McDonald here and we were -- really, by adding at the end of the fourth bullet for the electronic exchange of such information, say "and related information" might be a -- I mean, I am not sure that is good English. Is it good English? Okay.
DR. MC DONALD: Comma and related comma information -- so, it is medical record, and related, information.
[Multiple discussions.]
You would say in the second to the last line, "adoption of uniform data standards for patient medical record, and related information," just to encompass the other things.
DR. LUMPKIN: Okay. Let me read it and see if I understand what you are saying. "Based on public hearings, consultation and analysis, develop recommendations to the Department and legislative proposals for subcommittee and full committee consideration to promote the adoption of uniform data standards for patient medical record and related --
MR. BLAIR: Well, I think it was key, the patient medical record information and -- the comma comes after "information."
DR. LUMPKIN: Adoption of uniform data standards for patient medical record information and related information. Adoption of uniform standards for patient medical record information, related information and the electronic exchange of such information.
MR. BLAIR: Just my thought because I don't really care so much about the wording, but just to bring you back to -- I think the original phrase was "issues related to uniform data standards." Do you not feel that that phrase can cover things like decision support rules for representing knowledge, as well as patient medical record information or the processes related to the processing of medical record information? Because I thought it did. If you don't, then we could add this.
DR. LUMPKIN: I think the difficulty here is this one is talking about adoption of uniform standards and that is why the issues related to the language doesn't quite work there.
MR. BLAIR: Oh, okay. Well, maybe I am not quite hitting it. I thought that it said to study issues related to uniform standards in the law --
MS. COLTIN: That is what the law says, but the workplan --
DR. COHN: Let me just re-read this piece, which is based upon public hearings, consultation analysis, developed recommendations to the Department and legislative proposals for subcommittee and full committee consideration to promote, underline promote, the adoption of uniform data standards for patient medical record information. We are talking and related information and electronic exchange of such information. That is different, obviously, than the wording of the law, which was "shall study the issues related to adoption."
Now, it may be that we want to wordsmith to deal with the issues that have been brought up further. I bring that up as a question. And certainly if it is not ready, we can take it back and work on that a little more, Item 4, but let's talk about it.
DR. LUMPKIN: Are we conceptually okay with this? Maybe we can ask Simon and Jeff to come up with language for tomorrow when we present this to the full committee that embodies what we talked about and the work group will have an opportunity as individual members when we hear that brought back. If we have strong problems then, we can make adjustments.
DR. COHN: And I think what I am hearing from everybody is that everything is okay except that there are just some wordsmithing issues around Bullet 4 that we need to address. So, we will bring that back to the breakout session tomorrow for --
MR. BLAIR: Do I need to then procedure-wise withdraw my motion to approve it until tomorrow?
DR. LUMPKIN: My inclination would be to just approve it.
MR. BLAIR: Approve it with wordsmithing.
DR. LUMPKIN: And authorize you guys to wordsmith it before it is brought back to the full committee.
Any other discussion on the motion, which is to adopt it with the changes and soon to be wordsmithing?
Second?
MS. COLTIN: Second.
DR. LUMPKIN: All those in favor say "aye."
[There was a chorus of "ayes."]
Opposed?
[There was no response.]
Okay. Thank you.
DR. COHN: Let's begin the discussion on scope and deliverables if that is okay. I think we have some time to do that.
I am going to turn it over to Jeff in just a second to talk about the scope and deliverables that he included in this EMR workplan and I want him to speak at a high level about all of them and the rationale for them. Then I want us to just sort of go through and look at them one by one, just sort of what we think is in scope, what is out of scope. Are we missing anything, to begin to help guide further revisions of the scope and deliverables?
I just want to comment on this. I was thinking about this area. What I realized is that even as clear as we are about the legislation, there really is a fair amount of ambiguity about really what it is we are trying to do.
As I thought about really this wording about uniform data standards, electronic exchange of such information, I just want to bring to the committee's attention, the subcommittee's attention, that there really is a relatively wide spectrum of ways to interpret this and it varies from a relatively narrow focus on messaging that goes between systems, which is sort of the initial start, which has been done by a number of other standards organizations, you know, to do things, such as Kathy Coltin was talking about, getting from a CPR to a lab system and potentially back.
Then slightly broader is the issue of standardization of data within a CPR for use for benchmarking and other sorts of comparative information. And then a step beyond that, at least to my view, gets to be this issue of sort of coordination of care, where, you know, a hospital or a health plan might, after you take care of a patients, but might send them someplace else for other aspects of their care and need to get that information back in a way that they can use, which is once again a further extension of this sort of conceptualization of uniform data and electronic exchange.
Then, finally, we move even a step further, which -- you know, once again, I don't know where we want to sit, but we need to think about this, which is having to do with our patients and our providers and the environment that we live in where a patient may be or a person in our society may be a member of a health plan, receiving care from a certain provider for a period of time, may either leave that health plan or leave that provider, either for personal reasons or because of geographic relocation and go to another environment. And how does that information follow them in a way that isn't fax, which is the way that things typically follow them now or xeroxing, which is another methodology?
And then what happens if two or three years later they come back again. I mean, how does that information exchange and move through our system in a reasonable fashion? Now, as I said, I mean, that is a wide spectrum. I am not suggesting that the work group or the subcommittee or the NCVHS take on all four items, but one has to be aware that there really is a relatively wide spectrum of possible ways to interpret what we need to be doing. And they have different implications for scope and deliverables.
Jeff, do you want to talk a little bit about the scope and deliverables?
MR. BLAIR: Yes. I think this might have comments -- is that what I am handing you? Can I hand this to you? There should be 18 copies of comments on the workplan from Bob Mays and from Kathleen Fyffe. If you don't see it in there, then it might be in here. So, I am going to turn that over to you.
I think -- do all of you have a copy of the preliminary EMR workplan? You should have gotten it during this previous month. Is there anybody that doesn't have a copy because I have just a few extra copies just in case you don't have it? Okay.
The intent was for the document to serve as a catalyst just to get us to begin to focus on this work effort. We have got him until August of 2000 to be able to come up with the recommendations and proposed legislation on the subject area.
If you take a look at the document, it is intended to be kind of like a straw person to try to jog your thoughts a little bit. Let me just take you down some of the six major areas of focus, just to give you a feeling for what is in it. And this doesn't mean that these should be the right ones or that we should even look at it from this perspective.
The first one is trying to stay close to the intent of that phrase, "uniform data standards," and it indicates that it is focusing on message format standards, on patient clinical information standards. By that, we mean data sets, data definition, data models and data elements and also code sets.
We have got a little bit of a running start. I guess tomorrow they will distribute the inventory of clinical information standards and it is a compilation of these. It has got 79 different profiles to cover these areas. However, it is a compilation. It is not an analysis, an evaluation and that is something the committee will have to begin to look at if it chooses to go forward with this area of focus.
The second area might be data security, as distinct from privacy and confidentiality; data security being the information systems implementations to be able to ensure privacy and confidentiality. We are hoping that by September, ANSI HSP(?) will be able to deliver to us an inventory of data security standards. I should say standards and guidelines because many of them are policies and practices as well as specific information systems standards.
The third area that we might consider including within our scope is related to data quality and I think it was Kathleen Colter that gave us a picture of that in our last meeting. The essence of this is are we capturing information into that information system with standards so that we have got some good useful information to be able to pass on and interpret once it is into the information infrastructure.
The AHAIMA(?) has done work in the past in setting some guidelines for data quality. I think the JCAHO has. Kathleen might be able to indicate other organizations that might be able to help us understand this area better to see if this is an area we should focus on.
The fourth area that we might consider including within our scope is the area of trying to get uniform laws, model legislation among the states. I come to this with a vendor viewpoint. If a vendor is trying to come up with information systems to facilitate the information infrastructure and they have 50 different variations of that software solution, it may be either very expensive or impossible for them to provide that solution. So, it is a major impediment to going forth with computer-based patient record systems if we fail to get national standards in these areas.
Now, in terms of privacy and confidentiality, a number of the health care bills are already indicating preemption of state laws. So, you know, that is covered to some degree. We have other areas that are going forward. However, not all of the areas of uniform state regulations related to electronic patient record information is necessarily being addressed. For example, retention of the records, electronic signatures maybe, if we come up with federal legislation or guidelines for security, it might cover standardized electronic signatures and authentication; maybe, maybe not.
I mean, these are the types of things that we may or may not want to consider within our scope. The next area, although it is No. 5, I would tell you this is the area where I think -- and I think Simon may share my feeling with this, is one where we really should focus on. The reason is this. I mean, at least the way that I have viewed it is as we go forward with this work group and our workplan, we want to identify the areas where we can be a catalyst to facilitate things that are being done in the private sector.
To some degree, you could look at all of the -- at least the first three and see that the private sector is moving forward, maybe not as fast as we would like. Maybe we could be a catalyst in those, but in this fifth area I think that we really may need to assist and the reason is because once you get into the area of convergent medical terminologies and vocabularies, you are dealing with a number of professional associations that have limited funding standards organizations that are on a voluntary basis and it is very, very difficult to wind up getting the funding in place to be able to put forward medical vocabularies that are consistent that could facilitate computer-based patient record systems.
The core of that came up in March when we had testimony from a number of folks. I think that it was the number one issue of concern of the people that testified to us at that point was the need for clinical data dictionaries, clinically specific data dictionaries. Even if you look at what is coming out in terms of either SNOMED(?) or Reed or the UMLS to be able to put in place the code sets, if we are going to put in computer-based patient record systems, the character has to change.
The private sector and the government, I think, has to go forward to create some kind of an infrastructure that does not exist today to be able to turn this into something where those code sets are being updated on a regular basis, where the level of confidence and the accuracy and reliability of them can support continuous availability where you have acute care areas.
Where people's lives are at stake, you can't afford to wind up having a code set that is six months or nine months old. Although we can accept that today, in the future, in the information age, that will no longer be acceptable. And we may need to help there. So, that, I think, is something that deserves at least discussion, if not adoption.
The last area is a matter of how far along we really get in terms of discussing some of the scopes that we have here, the areas, where as we begin to move into the information age and more of this information is stored in electronic media formats, one of the aspects we touched on before was retention of information. Do we need to begin to think of the fact that even with electronic media you may only be able to retain information for ten years or five years and, yet, we are expecting this to be the foundation for lifetime health records?
So, that is what that begins to touch on. These are ideas. I am hoping that you had a chance to -- did you find Bob Mays' e-mail and Kathleen Fyffe's to distribute? Great, because Bob Mays really seriously questioned whether this was too ambitious and maybe -- these may be right topics but maybe we don't have the resources or time to be able to do this. I hope Bob is here.
MR. MAYS: Yes, I am here.
MR. BLAIR: Great, because, you know, pragmatically you could wind up becoming -- I think we have to be realistic in terms of what we can do and Kathleen had a number of questions and issues.
Michael, are you here, Michael Fitzmaurice?
PARTICIPANT: No. Mike will be here tomorrow, Jim.
MR. BLAIR: Okay. He made his comments on the actual document. As long as he will be here tomorrow -- he pretty much felt comfortable with the document. He just made minor changes. So, I don't feel that it is as urgent that he is not here today, but I think I have at least given you some feeling for how we began.
The other parts in the document, to be honest with you, are not there for you to look seriously at from a standpoint of implementing, but I fleshed it out a little bit more to wind up saying, well, how would we approach -- if we decide to include these in our scope, what kind of things would we need to do to be able to get to the point where we could make intelligent and perceptive and constructive recommendations?
And then I started laying that out on a time frame, just so we could get a feel for the magnitude of the issues. That is the only purpose that that is intended to serve.
Simon.
DR. COHN: There is a lot here and I think it is hard to know how best to approach the discussion even. I think what I would propose is just general questions about -- for clarification and all that and then maybe we can sort of quickly or reasonably quickly look through one piece of scope and deliverable to another to see if we generally think that they are in or out of scope, to help guide the development of sort of the next generation scope and deliverables, as well as the question being, you know, what is missing.
Is there an issue of prioritization? Because I think that clearly we are going to get to some things being in and some things being out and some things maybe just being of either low priority or having to be deferred until after the year 2000. We just need to begin to get some sense of that from the group to help us fashion another version.
MR. BLAIR: Can I just make a comment? I think what Simon is outlining in my mind is a good way to do it. Bob Mays, would you feel comfortable if we discuss these items from the standpoint of almost like our wish list, what we think are important issues to be included within the scope and then when we finish those, maybe we will eliminate two or three or four or five of them, you know, and a lot of your concerns about our resources being overextended might already be addressed.
If not, if we wind up saying we want these or different ones, then at the end we could begin to look at resources and what is realistic. Is that okay if we do it in that sequence?
MR. MAYS: Well, I mean, I think the committee should make your own decisions. I was just making comments and I would like to clarify, Jeff, that I didn't really have -- my issues were not around the scope of the types of issues. I think you have made a very good picture of exactly what concerns have to be addressed in terms of if you are going to truly move forward with a computer-based record system.
My concern was the amount of detail that the committee wanted to get into in terms of proposing standards. Some of the things that we have already gone through with administrative simplification, I think, illustrate -- you know, you can get lost in a really, really minute level of detail and here we are talking about not just ten transactions, but just a tremendous thing. So, I was really concerned that we or that you, actually, stay focused on this larger picture that you just painted.
So, I agree completely with you. I think that that is really what needs to be looked at. It was really just a concern at how detailed are we going to get. Are we going to actually get down to the committee thing? There should be this data set in ERs and that data set in OB, et cetera, et cetera.
But I look forward to hearing the discussion here.
DR. COHN: Well, Bob, why don't we have you come to the table here for the discussion since you are going to be part of the support, we believe, to help make this happen.
Dr. Kolodner, are you available to come in and sit and join us, too, for this discussion? Kathy, do you want to --
MS. COLTIN: Just one way to think about the scope is to say what is it that we really feel must be done within the four year timeline that was laid out in the legislation versus what are all the things that we ultimately would like to weigh in on. That may be a way of prioritizing among the short term versus the longer term needs, not to necessarily exclude those longer term issues from the charge, but to not commit to weighing in on those within that timeline.
DR. COHN: Kathleen, were you going to comment?
MS. FRAWLEY: Are we starting our comments or --
DR. COHN: We are just talking about high level issues and then we will start moving into --
MS. FRAWLEY: This is a very comprehensive workplan. I guess for me No. 5, which has to do with clinically-specific data set and codes is incredible. Item 5, which is the clinically-specific data sets and code sets, to me, that is the most critical item for this workplan.
Some of the other issues, while they are important to me, are probably less significant because there is already -- we know there is going to be security standards that are coming out. So, certainly that issue is not as critical. I mean, there are accreditation and licensure groups that require specific content of medical records.
Again, you know, I think that is something to keep track of and not necessarily a major focus. So, to me, all of the items that you have under 5(e) is really --
DR. COHN: Where --
MS. FRAWLEY: In your workplan.
DR. COHN: Yes, I am just looking -- try to focus for the moment on scope and deliverables, which is really in the introduction, just to make sure we stay high level. Let's not delve into the work yet. I want to make sure that we have the right target.
MS. FRAWLEY: Well, it is (e).
DR. COHN: You are in favor in (e).
MS. FRAWLEY: (e).
DR. COHN: I think it is important that before we delve into the workplan, we make sure that we are pointed in the right direction. Then as that begins to be reconciled, then we can really talk about how we get the work done.
Generally, are there other comments on -- I mean, not in the specific "yes" or "no" on the various numbers, but just generally what --
DR. MC DONALD: Generally, the security one, it seemed like it repeated another committee or it was dealing with the same issues. I know this is the specific focus to medical record information.
You have a report out on security.
PARTICIPANT: It is this committee.
DR. MC DONALD: Never mind.
Well, you spent a lot of time working and I read a report about --
[Multiple discussions.]
Well, they look -- well, then maybe that is my confusion because this looks like access control, authentication, some of those things are --
MR. BLAIR: We try to stay tight with data security on that as opposed to legislation for health care privacy and confidentiality.
I don't know. Kathleen may be able to help us make a more mutually exclusive separation. That was an attempt at it anyway.
MS. FRAWLEY: That is okay. I mean, I thought you did a good job, Jeff. I just think that when the security standards are published, you know, that I think that will be less of an issue in terms of our workplan because, obviously, people are going to have to adopt those and that is going to influence their patient medical record system.
DR. COHN: Are there general comments before we start going item by item to ask for input?
Okay. Rob, if it is okay, in talking about GCPR, why don't we do that right when we are done with the discussion around scope and deliverables.
DR. MC DONALD: In your introductory discussion, there is sort of this -- there is a distinction made between data when it is being sent around and data when it is in the medical record. I don't think that is right because most of what goes in the medical record gets sent to it. So, if we really create independent thread about how we standardize data when it is being moved around versus how we standardize it in the record, we may end up with things that don't work.
So, at least I think we ought to be, you know, conscious in the front end that anything that is in there might want to be sent to someone else. And you actually mentioned, you know, when you sent out people for referrals or for secondary care.
Just to make sure that gets threaded in here, that we don't get them two separate threads in two separate work areas.
DR. COHN: I certainly would second that personally.
Other general comments before we start moving just sort of item by item to ask for just a general sense of both prioritization and in and out of scope.
MR. BRAITHWAITE: I was interested to hear from Rob Kolodner about how this scope relates to the scope of the kind of standardization project they are working on in GCPR because it seems to me we might be able to learn something about how we can scope from their experience.
DR. COHN: Are you suggesting we listen to GCPR at this point and --
MR. BRAITHWAITE: Or at least to comment about the scoping issues that they ran into.
DR. COHN: Okay. Please.
MR. KOLODNER: Thank you. I am at a slight disadvantage having not seen the workplan draft, but we --
MR. BLAIR: Do you need a copy? Do you have a copy? If not, I brought a few extras.
MR. KOLODNER: Okay. I think both Bob Mays and I probably need copies if they are available.
In listening to the scope as you outlined it, we really started in GCPR by looking at what it is we needed. Our original charge by our superiors was to develop a common medical record and different people interpreted that differently, including that we had to buy the same software.
We decided when we got together that for a number of reasons, including the fact that each of us was at a different stage in our computer-based patient system, our CPRS, that it would take longer to do that than to focus on the core set or what we called the computer-based patient record, the data separate from the system.
Now, we haven't wrestled at this point with the structure of the medical record versus the data in the medical record or the information in the medical record. I suspect we will need to get to that, but we are stepping through and given that the partnership is now five months old, we started by seeing what the target was and then are starting to approach it.
So, for example, we know as we move forward that we will first define what we are calling trigger events. What are those events that cause us to need to exchange information amongst the partners? Then within that we will identify the particular data information that is needed about the patient or set of patients and then looked at how we standardize that subset. We can't do it all.
So, we are approaching it by doing a chunking. We decided to stay away from certain things that had to do with the system itself, inside the walls of each of the organizations. For example, the area of data quality is something each of us needs to wrestle with, but the idea of trying to standardize that as part of our focus seemed especially difficult; very important, but especially difficult because of the different procedures that each of us might have for capturing that data and validating that data.
So, we are taking the approach of drilling down a little bit and following a path, knowing that it will expand, knowing that there are some issues that we haven't yet dealt with. The data representation data model, knowledge representation are the area that we are focusing on primarily.
We will have to put in place security policies and standards for exchanging that information, making sure that if we have a system for exchanging the information, that somebody doesn't abuse that. We have various things, various methods for tracing that in some fashion or preventing that, if appropriate.
Clem McDonald mentioned in the conversation we had a little earlier this morning, one of the challenges is how do you have access to that information and then not prevent it in an emergency but still have appropriate security. We have not -- we know that is within the scope of what we will have to address. We have not come up with the solution that we will be adopting.
The communication message formatting is certainly one thing that we will include in our scopes. We really have five entities that we had identified, the trigger events or use cases, I think, is what some standards organizations call them, these data model data representations, the standards and the communication.
That is at this point what we have primarily focused on. Whether we will get into needing to identify the problem list as an entity with certain data, I suspect we will. We have not even close to that in our first step and I think that we have focused most of our information on what would be No. 5, the vocabulary issues as a very first step because we figure that if we don't have the vocabulary in place, then aggregating it into other entities becomes relatively meaningless.
DR. COHN: Thank you for your input.
John.
DR. LUMPKIN: I have a -- I have been trying to figure out my uneasiness with this issue and I think what it boils down to is I just wonder if we are in the situation of trying to describe an elephant from different viewpoints. I am not sure that we have an agreement on the vision of where we want to go. And if we make the assumption that we all have the same vision of what this electronic medical record is and we begin to move towards standards and we have, in fact, differing views of what it is and what it should do, we are going to run into a lot of problems down the road.
So, it would seem to me that the first step ought to be a statement of vision of what we think an electronic medical record is and what we expect it to be able to do in the clinical setting, in the practice setting, in whatever setting. I would hope that maybe as a first step, a very high level description of what it is we are trying to achieve would make it easier for me to get comfortable with some of the specifics that we are talking about as we go through the workplan.
MR. BLAIR: I think that is very appropriate. I think some of us probably started off with that vision in the back of our minds.
Let me ask you about this. The Institute of Medicine did the study in 1990-1991, an 18 months study that produced that. I would almost call it a reference book, The Computer-Based Patient Record and Essential Technology for Health Care, and then it has been updated. And, Simon and Clem, I think you wrote the first article that went in there. So, I just was assuming that the vision that came out of the Institute of Medicine -- Don Detmer, I think, was part of it -- obviously, was part of it as well -- may I offer a suggestion that could we start with that and maybe synthesize down a brief description that comes out of that study? Maybe somebody already feels that they had that.
Simon?
DR. COHN: When I hear the need for a vision, I do tend to look back at that book, which as we know was recently revised and actually I think there was a forward developed for it. So, I think it is probably useful for us to take a look at it. Certainly, the executive summary of that might be a very useful piece for us all to review as we begin to try to finalize scope and deliverable.
Now, John, I think that I share some of your concern about the overall vision. I was hoping by the fact that we were talking about rather than standards for CPR, that we were talking more about uniform data standards for patient medical record information and the exchange, that was hoping to ground us a little better as opposed to trying to figure out all aspects of what a CPR should be.
I may be wrong, but that was my hope that by the language of the legislation it may be focusing and grounding us a little better. I guess I should ask, do you think that that helps or do you think we need to look at the executive summary for the Institute of Medicine publication?
MR. MAYS: This is Bob Mays.
Just a comment. This sort of gets to what I was commenting earlier on, when I wrote my e-mail to Jeff. You know, visions, almost by definition are inclusive. They are broad enough that they allow certain interpretation, particularly in a realm like this, where we are talking about just tremendous variations. I think that that is -- I think we need to have that and then also relying on the experience that the GCPR project has had just initially with trying to over really just three or four organizations come up with how will we actually implement something like this.
I think they can all agree on the vision but the implementation, they have already begun to say, well, we are going to block these parts off and worry about those individually. I was sort of trying to get to the point in my comment that I think the vision is very important. I think it would be useful to articulate the vision and then I think that one of the real benefits that the committee could offer would be to identify those areas, which need to be focused on to enable that vision, not necessarily at an implementation level specifically.
I mean, you know, this is -- I refer back to our conversations and we will hear more today about the claims attachment and there is this philosophical discussion going on and continues to go on as, well, should it be claims attachment or should it just be attachment. In other words, are we talking about information that is only for adjudicating a claim or are we talking about a standard that for any other information requested, and I think that we will find as we broaden the discussion to the record that is just going to be repeated more and more and more almost over any standard if we really delve down to saying, well, you know, here it is. Here is the implementation. Here is the implementation guide for that standard. Here is the one way you can do that.
So, it is really, I think, very useful to pull it up, define the vision and then define those areas where you need to have some movement, some national legislation to enable that vision. The vision enabling might look different from state to state, group to group, in terms of its physical implementation.
DR. COHN: You know, I think what I am hearing that we do need to sort of revisit the vision and make sure we are all on board and I think that that should be an early -- that needs to be insinuated in here as a key piece upon which we check our scope and deliverables against to validate them. That is another piece of validation that I hadn't immediately thought about.
I don't think it prevents us from making progress today but it certainly is the piece of how we get to final comfort with scope and deliverables.
Kathleen, did you have a -- did you raise your hand? I am sorry. I guess you didn't. Okay.
Would it be okay, recognizing that we need to put that in, can we talk about each of the pieces of scope, at least at a high level?
DR. LUMPKIN: Actually, I am just suggesting that for a deliverable that as we go through this process if we have a document that comes out early, you know, even if it is a page or two, even if it is a summary of the IOM -- I mean, the NOM document, that is fine.
PARTICIPANT: IOM.
DR. LUMPKIN: It is an IOM?
PARTICIPANT: IOM.
DR. LUMPKIN: Well, anyway, I think that would be very useful in saying at least that when we put it out there, let's make sure there are no surprises and someone says, well, that is not exactly what I was thinking about. I suspect we will all be on the same page and I think that will be good. Sometimes it is important to be explicit rather than implicit on what we agree on.
DR. COHN: Having said that, let's talk about these various items that Jeff had proposed, just to begin to get a feel for what is on target, what is off target, what needs to be revised, recognizing that we still have that sort of piece hanging out about the vision.
MR. KOLODNER: Simon, one other thing in addition to the vision that we may might to also define are what might be called principles that will guide the scope. And I know that when we were dealing with health care reform and the informatics or information aspects of that, that we made a conscious decision not to try and affect what was put on paper, for example, but talked about the boundary being when information left an institution so that if they wanted to write in hieroglyphics in the medical record. That was their business decision, but it was when information had to go out or come back in that that is where it became affected by the realm. That was where we drew our line.
DR. COHN: I actually think you are right that we need to have principles. I am not sure that the principles would necessarily be exactly where you draw the line though. I think that is something we need to think about.
MR. KOLODNER: I agree that the principle is not where you draw the line, but it is the things that help you to draw that line. The idea of are we affecting an individual practitioner, are we affecting a group, are we affecting a multi-site institution may fall within it. But, again, how you define those principles should guide it.
MR. BLAIR: Can you help us? Would you join our committee and work on that?
MR. KOLODNER: Well, I think I have been volunteered to join your committee.
DR. MC DONALD: I think the point is a good one, though, about the principles, about what we are really trying to do. And the other one to draw the line is whether it is enabling or prescribing. Frankly, I would be on the side of enabling, rather than prescribing, at least at this stage in history because you get so much push back from prescribing.
I mean, if we say one must send these 500 variables every time -- and I think this is actually something that may be in disagreement amongst the committee or we maybe need to talk about, versus saying if you are going to send something, this is how you send it because that means more work, perhaps, for the providers.
MR. BLAIR: I guess you get into these things and you sort of have maybe assumptions, which you might otherwise call principles that are in the back of your mind and you don't articulate them because you just go forward. So, one of the assumptions, ala principles, that are in the back of my mind that you may or may not agree with -- and if we don't, then we could go down -- you know, we would revise this accordingly, but I am just keenly aware of the innovations and progress that vendors and providers and standards organizations have made during the last five to six years as they have focused on that -- the ones that I have known have for the most part accepted that vision that the Institute of Medicine set out on computer-based patient record systems. You know, a lot of people wind up -- especially, Rob, I think as you get into this thing, the first thing you wind up saying is, gee, not all the standards are there. So, you immediately hit what is not there, which is what we all do when we are trying to pull together a system and sometimes we lose sight of how much has been done or is being done.
My thought is that it is our rule to really understand what is going on in these professional associations, the standards organizations, the vendor community, academic medical institutions, all these folks that are working on these issues to try to come up with solutions to find where they need some help. The help might be in some piece of infrastructure that they can't create but that the Federal Government can assist with, either in terms of laws, in terms of subsidies, in terms -- there are just all of the different ways in terms of being a forum, in terms of research grants or studies or whatever, where we can focus this to have the greatest effect.
So, at least I am viewing this work group's effort to be a facilitator and a catalyst -- Clem used the word "enabler" -- in some cases an enabler, but in other cases a catalyst, a facilitator, a sponsor, a forum, whatever it is to facilitate what is going out there in the private sector.
DR. COHN: Basically to try to wrap up this particular piece, I am, obviously, hoping that the GCPR will have some principles and other things that we can begin to review and look at to see how applicable it is to the work group's activities.
With that, can we go through the various elements of the scope for a couple of minutes just to sort of look at them to aid for subsequent revisions?
I, perhaps, have divided them up slightly differently than they are here only because I tended to segment them into what I considered to be sort of measurable pieces. I think the first question I would have for everyone is does everyone consider the guidelines and standards for administrative and clinical message formats are within the scope of what we are talking about?
No complaints? Okay.
Now, the next one would be patient clinical information, in parentheses, data sets, data definitions, data elements, data models and code sets. Should we talk about that for a second?
Well, I have a question to bring up now. First of all, the question is do all of you understand even what those all are, but even beyond that, the question would be are data sets a piece of what we should be getting involved in? Data sets are very different than codes and they are very different than data definitions or data elements.
If you think about it, you know, it is one thing to specify data element, its definition and potential values. It is a whole other thing to say that this will be a data set for a particular purpose. Certainly, the NCVHS has gone there with the core health data elements previously and I don't know whether this is really a focus of what we need to do.
Kathleen.
MS. COLTIN: Just a thought. In all of the transactions that I have seen there is a specification for whether a data element is required or not required that moves you into the direction of a data set without necessarily naming it as a data set. Would you presume to specify for these data elements whether they are required or not?
DR. COHN: I guess, I mean, you are referring to in terms of each message, whether it is required or not or generally whether it is required or not?
MS. COLTIN: Well, if, in fact, the record needs to be able to support particular transactions and if those transactions require particular elements, then you move back to the point where those elements need to be in the system that will be either be sending or receiving those transactions.
MR. BLAIR: Clearly, that work needs to be done. I think that that is, as Bob Mays would say, at a level of detail that is more detailed than we need to get down to in our committee. Maybe there are two aspects here. Patient clinical information, and we gave examples, data sets, data definitions, data models, there will be some people that will look at that phrase and they will in their minds say, well, that is the content and structure of the electronic medical record system.
So, maybe that helps some folks to understand that area. The other piece is that for us to get into the details of what is in there, I think, is too detailed for us but Bob Mays, for example, is working on data registry and that is a key infrastructure piece that could enable and facilitate the standards organizations and other vendors and developers of computer-based patient record systems, which they may not be able to do themselves.
So, maybe that is the kind of a thing when we study this area where we could either help with -- well, help in whatever way is appropriate. The other types of things that might be appropriate as we look at patient clinical information might be maybe just a forum to get the different folks that are coming up with data models. HL7 is working on information models and data models and there have been other large organizations that have come up with their own data models.
I think Rob Kolodner probably thinks it will be horrendous if he has to come up with a brand new one that is incompatible with what Kaiser or Mayo is -- so, I think these were the issues related to patient clinical information, at least, that I was thinking of, as opposed to us actually getting down and creating the data definitions.
DR. MC DONALD: And we have opportunity for tremendous confusion in all these words. And I would guess -- I mean, data elements are part of the model if we are talking in models. And then data sets are my bogeyman in my life because they imply a flat data structure, which is unlikely to be the structures that will be evolving in the future.
The messaging people worry about all this stuff. So, if we said something like clinical message formats, patient information and data models and code sets, we might at least reduce some of the confusion words. There are still big ones in there.
MR. MAYS: Just a real quick comment. I can give you one area that would be very fruitful for us even just in the other parts of the HIPAA transactions that has to do with processes for determining data content. That is an area that we have not clearly been able to define, even for the administrative transactions. Who is going to be responsible for overseeing any content changes to those standards. I think that that is an area that would be higher up than specifying the data sets; you know, in other words, coming up with a process or guidelines.
Who should decide what is in an ER record or something like that? And who would review that?
DR. MC DONALD: Or should anyone?
MR. MAYS: Or should anyone.
DR. COHN: I have noted that comment and we will try to add it into the list of items.
I want to move back to this data set question, though. I guess from my own view, the proposal that I would make -- and first of all, I believe that in the context of administrative and clinical message formats that implicitly data sets are identified. That is really how data sets are identified in the real world, saying if you are going to send something from one system to another for a certain reason, you have to send these elements and these elements are optional, these elements are required.
Now, that is a very different way of approaching the data set than just adding it as another list on top of patient clinical information. So, I think my proposal, as I looked through this, was that we get rid of data set as a specified element, knowing that that would be -- once again, that is a very tough area for us to really make much progress in.
Anyway, is that a reasonable position to take?
Yes, Kathy.
MS. COLTIN: I would agree with that. That was really what I was trying to get at with my point is I think they are implicit in the transaction, but what I am not sure I see here is whether there is any plan to look at what types of transactions a computerized patient record ought to be able to support, sort of getting into the functionality a little bit.
I don't know which of these items would cover that or if you intended to cover that.
DR. COHN: Comments from others?
John.
DR. LUMPKIN: I think it gets to my mind to an issue that Rob raised, that they are looking at with the GCPR project, which is to look at where the systems interact. That is one level of standardization.
You raised -- when you gave your initial presentation, you talked about what about a patient who moves from one practice to another and something that is near and dear to my heart, what happens when that patient shows up in the ER at 2 o'clock in the morning. Then it may make a difference whether or not that record is written in hieroglyphics because the complaint that that patient shows up with is what I am concerned about.
And I may need to review records going back for a number of years to try to determine whether or not this abdominal pain is related to their cancer or it is a new finding. And, how much, you know, specificity should I be able to pull out of that kind of record?
So, I think those are the kinds of issues that I am much more comfortable having us try to establish than on the other end going into the data sets because once you get there, then it becomes -- while we may not have standards, it certainly sets the directions for further standards development. I think that ought to be part of our charge.
DR. COHN: Okay. Thank you.
Are there other -- yes.
MR. KOLODNER: The issue about the hieroglyphics, I mean, if it is within an organization, then I don't think it is -- I think it would be difficult for this committee to mandate certain things within an organization as to how they are going to do business. They will either stay in business or go out of business, depending on how well they do that. But I think that we really don't affect it down at that level; whereas, we can say in an emergency you have to provide this in such and such a time frame in this format and I think that if they can do it out of the hieroglyphics in that time frame, they can.
So, again, it keeps us up a level from how an organization chooses to implement it, where they touch the providers as opposed to what we really need, which is caring for this patient or collecting statistics for particular things in public health or other types of things.
I think if we stay at that level, then it keeps us from getting too nitty-gritty and where we are going to run into all the resistance or a lot of the resistance in terms of trying to affect people and organizations specifically in their processes.
DR. COHN: John.
DR. LUMPKIN: Well, I think one of the things that we struggled with and we came to some resolution in looking at the administrative transactions is that we don't really care what format people keep their individual records, as long as they can pump it into an EDI engine and then communicate it to me. I think that is the kind of -- we may be saying the same thing, I think.
DR. COHN: I think the devil is in the detail on this one.
Yes, Marjorie.
MS. GREENBERG: I think to some degree this is semantics because it gets back to the functionality. If you want your CPR to be the source for, say, a death certificate or a birth certificate, then, obviously, it has to include the data that is in those data sets or those data sets have to adjust to what can reasonably be collected in the CPR.
So, your functionality leads you to a variety of data sets, which would be beyond the scope, I think, to define them and are being defined in various different organizations and, as Bob said, that is kind of an evolving process and who will be defining these and who is going to be defining the content of the transactions.
So, I think in a sense, I mean, it was useful for the clinical inventory that the ANSI HIS developed to ask for among other things to be reported on to hear about data sets because it gives you somewhat scope of at least what various groups think are important clusters of data. So, I think that has got to be -- you know, just as Rob was saying, they are looking at the core, I mean, what data are going to have to be exchanged that in some ways will be defined as kind of a data set.
But if the committee or the subcommittee is concerned that it should not be in a position of having to define the data set for a computer-based patient record, then I would concur.
DR. COHN: I have a comment and then I will give it to you, Bob.
MR. MAYS: A brief comment actually, though. Semantic management is actually a very, very important area when you start talking about a broad record like the CPR. Each individual data set developed by the appropriate group -- let's assume that they are all, in fact, extremely appropriate groups to be developing.
It is when you have to link them all together and manage those semantics in a coordinated structured fashion that the challenges really arise. I mean, that is an area that I think, again, takes it up a little bit of a level. You have to figure out how you are going to abstract it up to where you can deal with the fact that -- because there is lots of overlap in these data sets and with the core data set out of NCVHS, but there is overlap across all of these and we should try to come up with some structural approach that lets us manage that, you know, allows the different groups to view the world in the way that makes sense to them and, yet, allows us to aggregate it up into a sensible view as well.
MS. GREENBERG: That is why I think the registry is really critical.
MR. MAYS: That is one approach but that is, of course, what they are dealing with here.
DR. COHN: I guess I am hoping that some of this stuff may be handled by a vision piece to help place really what we are talking about.
Jeff, Kathy.
MR. BLAIR: I think, Bob, you were saying that we probably don't want to define what the data set should be or several people have said we shouldn't define what the data set should be, what the content and structure of the record, you know, that we leave those to a standards organization to do that. And I would agree.
I think the level at which we want to engage on all of these three things that we are looking at, the message formats, patient clinical information and code sets is -- does -- is there a need for us to help to facilitate or enable, using that word from Clem, interoperability? Are the standards organizations and the vendors, the payers and providers doing this just fine on their own or is there some areas where they just haven't been able to move quickly enough to be able to facilitate the interoperability?
I think that may be the key principle.
DR. COHN: Kathy, did you have a -- were you going to say the same thing?
MS. COLTIN: No. Actually, the only thing I was going to do was add to the comment I made earlier about transactions. I don't think you want to get into necessarily saying which types of transactions the records needs to support. I think things like direct order entry could be optional. On the other hand, having been in a situation where I was in an organization that adopted a computerized patient record system and about two months into it, the issue came up of a patient, who left the organization and wanted a copy of their records.
And there was no functionality in the system to provide a hard copy print of their medical record. It just had been designed for people who are interacting with it electronically. So, they had to quickly get programmers onto that. So, there needs to be some minimum, I think, functionality that gets defined.
DR. COHN: I think that is captured and I have it listed here. I am not sure how we are going to handle it, but as an issue that we somehow figure out the right level for the work group to address that whole piece.
I would like to move on if we can because I think I am hearing a fair amount about patient information and how it moves back and forth between messaging and all of this.
Are there any final comments about this, I mean, recognizing we will come back to this again? This is certainly not a complete discussion. Okay?
Let's talk about the next item, which has to do with guidelines and standards for data security.
MR. BLAIR: I think you didn't get to code sets, though.
DR. COHN: Oh, I am sorry. I had included code sets in that list. Was there any comment specifically about code sets? The discussion was around data sets and I think everyone was fine except for the data set piece is what I was hearing.
Guidelines and standards for data security? Kathleen, you had mentioned that you didn't think that that was a high priority item because it was being handled by other ways.
MS. FRAWLEY: Right. I mean, we will have the notice of proposed rule making coming out on security standards, which addresses a lot of these particular issues. So, to me, I don't think that it is something that the work group needs to reinvent or -- I mean, we don't have a lot of resources. So, I think, you know, in terms of priority that would not be something I would focus on.
DR. COHN: Other comments?
Bill.
MR. BRAITHWAITE: I think we have to be clear that it doesn't mean that we can't talk about it if some issue about the way the security standards are being applied to the electronic patient record is causing problems. We can certainly talk about it and make recommendations to the people working on those security standards, but I agree it is probably a little beyond the scope of where we ought to be focused.
DR. COHN: So, I guess what I am hearing from everyone is is that it should remain on the plate, what I would describe as probably low priority or at least not something that we are spending a lot of time and effort on.
Correct?
Okay. How about guidelines and standards for consistent documentation of patient medical record information, including policies and practices, content, quality and technologies, e.g., transcription, scanning, optical character recognition, voice input, et cetera?
Comments?
DR. MC DONALD: I would be inclined to diminish that one because it is enormous and it is very much into the business of the practices.
MR. KOLODNER: This was one, as I say, we only had four organizations and we looked at could we come to terms with something that we could get across the four organizations and felt that we would let each of us run our organization the way we needed to, but we would expect that when that data comes or when we needed to send something that that is where we imposed the standard.
DR. COHN: So, you consider that to be out of scope.
MR. KOLODNER: I would think it would be real difficult to make a difference in this one.
DR. COHN: Okay. Are there other comments?
I certainly -- my own feeling is I consider it to be sort of out of scope for what we are trying to do.
PARTICIPANT: I agree.
DR. COHN: Next is model legislation to promote consistent state laws, regulations for the acceptance, authentication, sharing ownership and retention of patient medical information and electronic form across state boundaries.
Comments?
MR. GELLMAN: I have a comment.
DR. COHN: Please.
MR. GELLMAN: I know that below you are trying to separate out the privacy and confidentiality issues. I think that for some of the issues in this list that is impossible. I am not quite sure what you mean by model legislation. Does that mean model state legislation? This set of issues runs right into and overlaps with substantial degree, but not totally, with all the privacy issues, the preemption issues and all that sort of stuff.
And the word "ownership" whenever we are talking about medical records makes me flinch as the wrong word. And I don't know what to do about all that, other than to comment on that and say that separating out some of these things from others is probably impossible.
DR. COHN: Bob, are you suggesting that maybe this is something that we should be delegating to the Subcommittee on Privacy and Confidentiality?
MR. GELLMAN: No. This is not a jurisdictional comment. This is a substantive comment.
DR. COHN: That was a hopeful jurisdictional comment.
MR. GELLMAN: No. Just an observation.
DR. LUMPKIN: I just wonder if this may be premature. I mean, the first thing is is that once we have a standard, what are the obstacles? If it, in fact, is a national standard, is there a national jurisdiction for which state laws would be preempted? So, I think it is something to identify as potential barriers and if those are, in fact, barriers that exist, then they should be overcome.
As I think about Illinois, for instance, in the arenas that we license in which there are state laws, hospitals, nursing homes, home health agencies, by and large, these issues can be resolved by rule rather than by legislation.
DR. COHN: Okay.
Jeff.
MR. BLAIR: Let me make a defense of -- when we heard our testimony back, I guess, in early March, and I don't remember who it was, but one of the people that was testifying to us indicated that their number one concern was the ownership issue, legal ownership. And I kind of -- I stuck it in here with the rest and I was keenly aware of the fact that privacy and confidentiality is addressing, you know, preemption of state laws. So, you sort of segment that out and there are other pieces. It is sort of like -- I sort of feel like certain things may be falling through the gaps and that it would be appropriate that we hear from vendors that are trying to create systems that are going to be installed in integrated delivery systems that go across state lines and are trying to market to providers and health plans across the nation what kind of difficulties they are having with the fact that there are different state laws, what impediments are those, so that we understand that. Whether it is going to be the retention issue or whether it is going to be the ownership issue, I am not exactly sure what they will wind up saying, but I felt that it should, you know, be on the table for consideration that we try not to let these areas fall through the cracks.
So, that was my thought.
DR. COHN: I think we have a couple of ways of how to handle this. I don't think anyone considers it to be really off the plate of the full committee. One option is to ask the Subcommittee on Privacy and Confidentiality to help assist with looking at this particular area and advise the work group how and if it should be approached.
Another is to just keep it as a work group activity and not give it as much a priority as the other items. I mean, my own view on this one is to ask the help of the subcommittee to see if they can help assist us with -- I guess I haven't figured out how to approach it -- actually approaching this issue and providing guidance to the work group. What are the thoughts of the subcommittee?
Yes, John.
DR. LUMPKIN: I agree with keeping it in but I think I should remind us that we adopted the principle of floor exemption for privacy and confidentiality that states would have the rights to have more restrictive privacy covenants. Given that, we are by definition saying that we are endorsing the system where the laws are going to be different from state to state, as they currently are and that mechanisms are in place for moving medical information across the boundaries.
Given that, I would agree that we keep it on the plate, but it would be a side dish and not the main course.
DR. COHN: Okay.
Kathleen.
MS. FRAWLEY: Yes. I agree with John. AHIMA developed model legislative language in this area four years ago. So, I mean, I already have that and I mean there is no need to do rework. A lot of states have gone forward under their rulemaking authority and have promulgated regulations that now accept an electronic record. So, most recently, Kansas put a notice of proposed rule making out. So, there is movement underway at the state level in their regulatory authority to address that.
The retention issue is very clearly already addressed by federal and state statutes and regulations. The only area that is like kind of sitting out there is ownership and in the scheme of the workplan, again, I see that as something that we can keep on the list, but, again, kind of -- if we get through everything else, that would be great and then if we got to that, that would be wonderful. But I think there is a lot of pieces out there that we don't necessarily need to worry quite as much about.
MR. BLAIR: Just a point of clarification. Reassure me when you did the model legislation, did that also cover authentication like electronic signatures?
MS. FRAWLEY: Yes. It was creational authentication and I can give you a copy of it.
MR. BLAIR: Super.
MS. FRAWLEY: And it has been adopted by some states. They have already taken that as a model.
MR. BLAIR: Would the NCVHS be able to play a constructive role to state our support of that? I mean, is additional support from us going to be helpful, that the states adopt that. I think it was only a few states that had adopted the model legislation.
MS. FRAWLEY: Well, I guess my concern is that it is a potential barrier but probably not a primary scope of our workplan.
DR. COHN: Okay. I hear that we want to keep this as a side dish, which I am --
MS. GREENBERG: Advertising idea.
DR. COHN: I think it is more dessert actually.
Okay. The next one is recommendations to enhance the coordination and maintenance of both administrative and clinically specific -- and let's cross out "data sets" here, since we already talked about data sets being off the plate -- code sets that can support the demands of a computer environment that requires continuous availability, greater interoperability, more timely updates and greater clinical specificity. We may rewrite this particular section, but you get the idea.
Views -- I mean, I think that this is central stage.
MS. FRAWLEY: Almost like at the top of the list.
DR. COHN: Yes, this is sort of central stage. That certainly stays on. Main course.
The next one is recommendations to promote the development of guidelines and standard for EMR storage. Let's just stop there for a second, i.e., permanence in media.
Comments?
I think it is out of scope personally. Any other comments?
DR. LUMPKIN: I think we should make recommendations for the permanence of the record.
DR. COHN: Okay.
DR. LUMPKIN: And then the institutions can determine -- I mean, they can put it on floppy disks and update it every two years if they choose, as long as they assure that there is a way to maintain this as a permanent record.
DR. COHN: Okay. So, you are actually speaking that we should keep it on the plate.
DR. LUMPKIN: Well, no. I am just saying that this says to guidelines and standards for storage, i.e., permanence in media. I am just saying that we have a recommendation that it be preserved in the format that will be good forever.
PARTICIPANT: That is a long time.
DR. LUMPKIN: Yes. We could argue about the number of centuries or decades, but I think the point is is that we don't get down into the mechanism, the media, the format because that is all going to change in 10 or 15 years anyway.
MR. KOLODNER: Yes. We may be able to retain it forever and never be able to read it.
DR. COHN: Right. I have got some records like that actually.
DR. MC DONALD: Especially through database formats when the programs might not be around in 200 years.
DR. COHN: So, what I am hearing is is that we would want to, perhaps, state some principles on this. It is not a main course, but it should stay on as something that we would want to make some comments about.
Now, what about EMR processing, i.e., standards for decision support rules, medical knowledge couplers, et cetera?
DR. MC DONALD: It seems to me that is going to be the most dynamically inventive area and it may be very hard to standardize that. That may not be a good thing to tackle. I mean, on the other hand, there are standards for -- there are formal standards for syntax.
MR. MAYS: Well, the Food and Drug Administration, of course, is moving into this area and it might be useful just to sit back and watch what happens with them. In terms of --
PARTICIPANT: Don't sit back.
MR. MAYS: Well, or you can weigh in, but I mean there is a lot of discussion now on the regulation of algorithms as medical devices, if you will, and decision support systems as medical devices. So, I think it is -- the committee would certainly be able to weigh in on that, but there is a lot of discussion going on right now.
DR. COHN: So, you are suggesting we keep it on the radar more as a side dish?
MR. MAYS: Well, no. I mean, unless you think that what the Federal Government is doing in other parts of -- I mean, you are HHS. FDA is HHS. I mean, certainly if you want to comment on what they are doing --
MR. BRAITHWAITE: I would think that the actual processing itself in this area would not be of concern to the committee, but what should be a concern is the ability to produce and communicate the information from the clinical record through those processes so that appropriate on-line point of service kinds of decision-making can be done, not necessarily what the rules are or how they are processed, but at least how to serve out the information from the record so that they can be, ought to be maybe the salad dish or something.
DR. COHN: Other comments?
Jeff.
MR. BLAIR: I am not sure what is entirely appropriate. Simon, you had a phrase, I think, on one of the other items, where you wound up saying maybe this is an area where we would think of either a policy or a principle that we would set forth.
I would think maybe this would fit in that area, as opposed to us, quote, adopting Larry Weed's problem knowledge couplers or anything because I think Clem's comment was this is evolving and we probably, you know, don't want to constrain or limit anything by endorsing one approach over another.
On the other hand, it is a very promising area and there is one other aspect that may fall under this. The word was "processing" and, you know, these object standards, basically like the patient identifier services and lexicon query services, where vendors are getting together in consortiums and agreeing on standards for the functionality and services. I didn't stick that down there, but, Rob, with the government computer-based patient record project, I think you have also been looking at some of those.
What are your thoughts as to whether you feel that additional support or is this an area where we should just leave it alone or do you feel like our involvement at some level is appropriate here.
MR. KOLODNER: In looking at it, I am trying to understand what we are trying to achieve and if the goal is to further the technologies and to facilitate them, I am not sure that making them rigid is what we want to do because it is a place of change.
I think staying at a high level makes sense. What we are focusing on for GCPR, where we are focusing is on the services that allow us to exchange the data. We still have left the decision support at this point with -- because that is at the point where the clinicians are interacting with the system. At least that is what our ideal goal is. That is really what we are defining as the CPR system, the particular software applications that the organization is running. Again, within the four of us, we haven't focused yet on that.
Now, it may be that as we get through some of the core areas, that it makes sense to get into those more, particularly as standards of care become accepted in certain areas, where we would say that if you didn't do this, then it is malpractice. The driving force for that isn't going to be our regulation. It is going to be the lawyer standing at the door if people don't do certain things and then you might have a set of reminders of guidelines that you could say if you adhere to this, then that is reasonable care and people would want to adopt it and you can put it out in a format that would encourage people to adopt, whether that is Arden(?) Syntax or something else.
But I think it is a soft hand rather than a hard hand.
MR. BLAIR: I would like to make a suggestion that this is an area where I think we do need additional input to the committee in the areas of processing, functions and services, whether it is decision support, standards, whether it is things like, you know, knowledge representation problem, knowledge couplers, whether it is object oriented standards. I think we just need to know more about these areas before we make the decision whether or not they are in scope. So, I think we need additional investigation on this.
DR. COHN: I think that is a reasonable approach.
Dr. Lumpkin, I do want to apologize. I realize we are running a little over on time. I am hoping that we can take about another ten, fifteen minutes potentially to let Dr. Kolodner talk a little more about GCPR and then just wrap up this section.
Is that okay? We will keep it as short as we can here.
MR. KOLODNER: I had the privilege of presenting to the full committee a few months ago and I don't want to repeat the things that are there, but maybe update you since our activity is one that is evolving sometimes daily if not weekly. I think that as I mentioned earlier, what we are clear about is the target and where we are going, what we call the goals, as well as our vision.
If you would find it useful, I can read those to you, but I don't need to take up time if people -- basically, we want to be able to advance public health and individual care and we are focusing on those individuals whom we share in common, which because of the nature of at least two of the major entities means that they are or were at one point in the military.
Where we chose to work together is what we consider to be a subset of the CPR because each of us needs more than we need to necessarily exchange. The issue, for example, is -- although we haven't gotten into this level of detail in our discussions, but the issue today of orders and whether an order was given for something as opposed to whether a prescription was given or a lab test was run and what the result is.
At least at this point we expect that we may not -- or I would expect, and I am speaking personally rather than for the GCPR -- we may not want a lot of the orders to come across; yet, we obviously need them internally to run our business and to track them. But I may want the results of that.
So, we really are scoped down from what I see is the charge for the work group and for the subcommittee. Now, although it is scoped down, it is a pretty big scope and we expect that we will need to take pieces and we will need to define what those pieces are. And our plan is to have both our clinicians and some of our key administrative people who know the operations of the organization work together to define what those things are, those trigger events that I mentioned earlier are use cases. And then even within that, to prioritize where we are going to start.
I don't know what the answer of that is going to be, but it could be something as small as a subset of data, of laboratory data, when we form a network of regional laboratories. So, we have to send specimens and retrieve the results across our organizations.
Or it may be something that is well defined but certainly not simple as physical exams. The service persons receive discharge physicals and that is an important set of information that we need for VA or, indeed, health service or LSU in follow-up.
Simon, you mentioned a couple of different levels and although I didn't catch all of them, it turns out that I think we are at the far end in that we are talking about having patients go back and forth and needing to move that information about the patient back and forth. And because of the transfer of people from the Department of Defense onto others. It is, in fact, the transfer of all of the information about that person or another entity.
So, we, in fact, are trying to address a very far-reaching type of operation, at least based on the classification scheme which you identified. We know that we are going to run into barriers. We know that, as Jeff had mentioned, there are lots of things that are there and there are an awful lot of things that aren't there. And, in fact, one of our goals talked about how do we advance beyond that.
We had talked about some things that although we didn't label them as principles really serve as that. One of the key ones is that we are -- that whatever we do must be open architecture and standards. That means that the set of information that we wish to exchange, we want to be in the public domain. And that runs into some obvious issues relative to some of the existing code sets that are there.
But to us that is absolutely critical and we believe that we have enough of a presence in the marketplace that we may be able to make a difference, that instead of some organizations trying to put together maybe 50 or a hundred organizations in order to have a certain size, that believe the four of us, particularly with the VA and DOD, that we bring a table of fairly substantial buying power, but also a fairly substantial intellectual capital, that if we can't achieve the goal that we want by negotiating with entities that may have the existing standards, that if necessary we may need to create some of the things that aren't there.
We, obviously, would not like to do that. But the preference of being locked into a proprietary system versus having an open public domain system -- right now, our emphasis is really on that public domain system.
Now, I know that in conversations with other people in other parts of HHS that we have also talked about. Maybe that is a role for government. You figure out what it is going to cost to get those things out in the public domain and you figure out how some of those code sets, at least, are going to be maintained and who is going to pay for them.
I think that is certainly worth discussion in the subcommittee. We see ourselves as complementary to the activity of the work group and one of the discussions that we have been pursuing and hope to actually effect is that the work group will serve as an advisory group to the GCPR effort. We have a goal that we have to achieve. We have to actually do some of these things. That is what we are being held to.
That means that sometimes we will push forward before standards can be in place, knowing that as those standards evolve we expect of ourselves to then adhere to those standards, but we can't wait for all the standards to be in place. What we may be able to do and what we think we can do is to catalyze that effort and we have been talking with HL7 about being a work group or a SIG, special interest group, to HL7, populated by our staffs or by our front line people, but in an open process that doesn't limit it to the four entities and where we can set a timetable that we need for a starting point for generating that subset of data or of the data model that is needed for our next chunk of activity and yet then putting that into the process of balloting and other processes within HL7 that allows all of the interested parties to participate and that the ultimate standard that is set has -- which may take awhile to go through -- has the input from the appropriate parts of the country, of the stakeholders.
Then we would be following that and modifying what we have over some set period of time that we would hope would be shorter rather than longer, to then adhere to that standard. In fact, and one of the things that had encouraged to pick this approach with GCPR is we are focusing on the care of the patient as a starting set for our activity and for any public health activity, rather than on the business processes that each of us has that are different.
And we believe that when it comes to taking care of people, that we are much, much more similar than different so that 80, 85, maybe 90 or more percent of what each of us needs is, in fact, the same, not that there aren't differences in vocabularies that we have been using, but that we can resolve those and that, in fact, the target that we have for that is the same.
That is what encourages us to believe that we can achieve the goal that we have set in a reasonable period of time.
DR. COHN: Rob, thank you. I think, speaking -- even though we don't really have a work group yet, I think as one of the co-chairs, I think I would speak that we, obviously, would be happy to act in an advisory capacity to the GCPR. I think I am hopefully speaking for the rest of the work group in that feeling. Obviously, we need to identify exactly how that should occur and what that means.
Certainly, you have said a lot of things and I don't know that this is really the time to delve into them all, except to comment that certainly some of the comments probably deserve wider discussion and more insightful dialogue about the pieces that you have identified.
Are there other comments or questions from the subcommittee on -- Jeff?
MR. BLAIR: Rob, to what degree do you envision GCPR is actually going to develop a government CPR system, as opposed to define the requirements and either subcontract to one or more health care information system vendors to pull that together for you? Or is that not determined yet?
MR. KOLODNER: Well, a couple of things. If we succeed in only doing the a government CPR, we will have failed. From the VA point of view, $1 billion versus $17 billion is outside care if we have LSU as one of our partners. But we really need to reach all those other people who care for our patients.
DOD has TriCare and they have a tremendous number of private sector providers that they need to be able to reach. So that if we form something that stops at the boundaries of the four partners then, like you say, we have failed. The role of the vendor that we find for this particular project within our partnership, which we call the GCPR framework project is -- we are in the process of -- there is an RFP on the street and it is out on the Web, but we are looking for a vendor, who will serve to provide a service that our best description of it right now, rather than a system -- and the best description that we have at this point is of a new utility service.
It is not a gas company. It is not an electric company. It is not a local telephone company that has the wires to your walls, but it is much more like a long distance phone company in that it does routing and switching. If I need information from certain entities, I go out via the Internet is what we expect that we will be doing and then it hits the service, which then routes to appropriate other places, but, in addition to just switching and routing, it also does translation. And that is a critical new functionality so that it can come in in one language or standard and can be translated so that it -- and brought together in a stream to the entity that needs the information and will be bidirectional, but doesn't control the wires down to the entities, the organizations' walls.
That is what we see our approach being in working with the vendors. Now, we have chosen to separate from the services we are asking for the data model and data representation, which we will be providing to the vendor and that is that entity that we want to have in the public domain rather than it being something that a vendor provides.
We are currently working our options in that area, both in terms of the data model and data representation, which we expect, at least at this point, to be working with HL7 on. And that is where we would be resolving the data models with the HL7 model, the RIM(?) model and --
MR. BLAIR: You don't expect to be a developer of application function per se. You are coming up with the data and with the network infrastructure and you are looking to vendors that can begin to use standards and interface into it. Is that what you are saying?
MR. KOLODNER: Correct. There will be a few applications that we expect will be part of that. For example, if there is an audit trail function that is part of that, then that may be an application that needs an interface, but for the most part, it is not the application of where the provider is interacting with the data. The information is provided to each of our information systems, which then has that function of providing and interacting with, providing the decision support and other things for the providers.
MR. BLAIR: As you begin to come up with this data model, you mentioned you are working with HL7 -- what are the other major sources of information for that information model are you pulling in? Is it vendors or is it Carser(?) and Mayo? Is it --
MR. KOLODNER: We are actually in discussions with all of those.
MR. BLAIR: All of those. Okay.
MR. KOLODNER: We had a flurry of activity last weekend.
DR. COHN: I don't mean to cut off just because I know we need to move on to the next topic, but I think we are just beginning -- at the very beginnings of this discussion. I was trying to restrain myself a little bit, but you mentioned the term "public domain" so much that I find myself requiring at least a very brief response that it may be that you mean public domain. I have, obviously, observed that many groups, such as HL7, are really not public domain standards, but are actually copyrighted standards that may be available for free or nominal charge and you need to evaluate that wording very carefully, if that is really what you mean or something sort of somewhat close to that.
So, I think that is a subject sort of somewhat close to that. So, I think that is a subject for further discussion.
Now, I just want to take a minute to wrap up and figure out what our next steps are and then go on to the next item of agenda, knowing this is just the very first discussion of GCPR. I think what we have done is we really have begun to establish the work group. We okayed a charter and a charge, which required a little bit of modification, which we will run by you at the next -- at the breakout session. It has become clear that we need to agree upon a vision and we will start looking at the executive summary of the IOM document as a starting point for that.
We also need to be able to engage in some principles. I think there is going to be a need for a major revision of the scope piece, which I know that Jeff and I will be working on and I am hoping that others of you, who may be interested off line may contribute to before we review that, hopefully, in the near future.
I think, tomorrow, assuming that there is time at the breakout, maybe we will discuss how far we are with those things, whether or not we feel comfortable even getting them out for comment by the end of the day on Wednesday. That will be part of the discussion that, hopefully, will occur with the breakout.
I want to thank you for all your attention for this.
MR. BLAIR: Simon, let me just add one last thing.
DR. COHN: Please.
MR. BLAIR: Is there any committee members that are here that does not be on the electronic distribution list for this work group on a continuing basis? Should we assume that all of you who are here want to be part of the work group? Because I think it is virtually the subcommittee. Is that correct?
DR. COHN: I see some people shaking their heads. I think we will have to, I guess, ask each member individually whether they want to be actively involved with this process or not.
DR. LUMPKIN: And also, we need to open it up to the full committee participation because there may be people who will participate on the work group, who may not be participating on the subcommittee.
DR. COHN: Well said.
John, thank you very much for giving us this time.
DR. LUMPKIN: Thank you. It is an important discussion and, as you said, an initial one.
Looking at our agenda, I would like to propose a change. What I am going to suggest is that we take a half an hour for lunch and get together at 1:15 because I know all you guys and I know if I say half an hour, it is going to really be 45 minutes. We will plan to get together at 1:15.
We have a little bit of give in the schedule. We are scheduled to discuss -- we have, I think, three hours tomorrow.
MS. GREENBERG: I wanted to ask you whether you have or plan to have a working session tomorrow afternoon and where?
DR. LUMPKIN: Is there somewhere around here?
MS. GREENBERG: I think you can meet in Jim Scanlon's conference room because the Subcommittee on Populations or Population Specific Issues, whoever they are, is meeting in here. I don't believe the Subcommittee on Confidentiality and Privacy is meeting tomorrow afternoon. They are meeting the following morning.
DR. LUMPKIN: Because we will need to review the full committee's response on the NPRM, incorporate that, and I think if we run into problems at the end of our agenda, we can push back the discussion on the hearing tomorrow.
Okay. So, we are going to take a lunch break.
[Whereupon, at 12:32 p.m., the meeting was recessed, to reconvene at 1:20 p.m., the same afternoon, Monday, June 15, 1998.]
Agenda Item: Review Potential Comments on Two Notices of Proposed Rule Making Now Open for Public Comment
DR. LUMPKIN: The next item on our agenda will be to review potential comments for the NPRMs. We will start off with NPI.
MR. BRAITHWAITE: Potentially labeled a draft NCVHS responses to issues raised in notice of proposed rule making, NPRM, on the national standard health care identifier. It is CFA45P.
Do you want me to walk them through it or what would you like me --
DR. LUMPKIN: Actually, what I would like to do is, Bill, if you would walk us through this.
MR. BRAITHWAITE: Don't be afraid when you look at this and see that this is a 12 page document. It is a draft document and it includes at least 50 percent of material that was extracted from the NPRM, just to put everything in context for purposes of this discussion today.
The draft starts off with a couple of general statements; one, reiterating the statement that NCVHS made in its position last year about the size of the NPI and whether it should or should not be alpha numeric. As you know, the NCVHS or the NPRM -- these acronyms are going to get to me -- the NPRM recommends an eight character alpha numeric position, an eight position alpha numeric identifier, which would start off with seven numeric digits plus a check digit and when we run out of seven digit numbers, then alpha numerics would be introduced, giving people time to adjust to that.
The committee discussed that last year and recommended a ten digit numeric instead of the eight position alpha numeric. So, we have quoted the original NCVHS position. In the interest of operational efficiency, we suggest the Department now also evaluate a slightly longer ten digit numeric identifier. That was the only comment that came in about the NPRM, about the character of the NPI itself.
Is there any suggestions, changes to reiterating our previous position?
DR. LUMPKIN: At this point, too, before we go to a walk down point, are there any other general comments that we want to make about the NPRM? This might be a good time to take those.
MR. BRAITHWAITE: The first page and a half is draft general statements. Besides a few good words there, the key is the two principles that are proposed in this draft; one that says that essentially we should define very clearly and explicitly what entities we are enumerating and for what purpose and what is suggested is that there are only two types of health care providers, human beings and institutions that deliver health care services.
The NPI, as drafted, in the NPRM also covers groups of providers, organizations, people that get the checks sent to, which are not providers of health care services. So, the draft recommendation from the committee is that this process should be simplified so that only identifiable entities that actually deliver health care should be enumerated as health care providers and that other mechanisms be looked at for identifying the other entities, which currently now use identifiers in a variety of ways.
For example, the "pay to" organizations could be identified by the IRS's tax identification number. Everyone of the people you pay have to have one of those identification numbers and that is unique to the organization you pay. So, why not use it?
Then there is a bunch of other organizations, amalgamations of individual and organizational providers for a variety of purposes, usually contractual purposes, as far as I can tell, but the NPRM does not identify those entities in a sort of coherent way, just that this is what the industry wants.
So, the recommendation suggested here, at least, is to focus on enumerating the two identifiable sources of health care services and find other ways to identify the other entities.
I will talk about the second general suggestion and then we can talk about those principles before we move on to the specifics.
The second one on (b) is that the information used for enumeration be simplified and only the essential information for uniquely identifying individual health care providers be used and that the function of enumerating uniquely health care providers be separated out from all of the other functions that the other data items that have been proposed in the NPRM might be used for, including enrollment and verification of credentials and research and all kinds of other things.
So, those are the starting two general principles and let's talk about them before we move on to the specifics because many of the answers to the specific things are dependent on these principles. Are these principles that the committee would like to -- subcommittee would like to support?
MS. FYFFE: I would like to support them.
MR. BRAITHWAITE: Would you like not to support them?
DR. LUMPKIN: Anybody -- I guess we are all on board.
MR. BRAITHWAITE: Except for Marjorie.
MS. GREENBERG: Well, I compliment the staff for putting together very comprehensive comments. I don't necessarily agree with all of them, but that is my prerogative, I guess. But I have a question and a point on each of them, if the chair will allow me to express them.
DR. LUMPKIN: You started. You might as well finish.
MS. GREENBERG: Okay.
When you talk about -- you are talking about organizations, individuals and organizations, not just institutions, right? At one point, the word "institutions" is used. So, you acknowledge organizations like community health center or something. When I hear the term "institution," I guess I start thinking about in-patient, sort of institutionalized, and --
MR. BRAITHWAITE: I think that the two concepts, if I can reduce them absurdly, are warm-blooded human beings and bricks and mortar or an address.
DR. LUMPKIN: What about home health agencies? Would that be the home health care assistant?
MR. BRAITHWAITE: Presumably, home health care agency has a central office or something that can be identified, although the health care is not delivered there. It doesn't specify the location of the service, only the location of the entity that is being identified.
MS. GREENBERG: So, there is a large taxonomy, I know, that HCFA had worked on and then worked on further with ANSI. It doesn't really call into question that taxonomy. I mean --
MR. BRAITHWAITE: I don't remember whether the taxonomy includes organizations that you might pay a fee to for a service that had been provided but didn't actually provide the care.
MS. GREENBERG: Yes. It might, such as like HMOs. I don't know whether you are proposing that an HMO -- well, it would have a payer I.D., I guess, a plan I.D. So, it should not get a provider I.D. Okay. But a school-based clinic would get a provider I.D.
DR. LUMPKIN: Let me follow that through. Let's suppose I was working in an HMO in some small state out West and this HMO, I don't know -- let's just make up an initial, that it starts with a "K," and they have a hospital and I show up at that hospital for an emergency problem. I am not part of their plan. They now bill me. Would that bill come from the institution, i.e., the hospital? Or could that HMO bill me?
MR. BRAITHWAITE: This doesn't say who bills you. This just says how do we identify who provided the care.
DR. LUMPKIN: In an emergency department, there is both a care provided by the hospital and care provided by the clinician. Okay.
MR. BRAITHWAITE: I mean, this is an issue that the implementation team has had to deal with and they have, obviously, come up with a slightly different solution. So, maybe we should hear from the team about the pros and cons of taking this approach so that we can have a more intelligent discussion about it.
For those listening, Mary Emerson has joined us as one of the co-chairs of the team working on this issue.
MS. EMERSON: I think that the vision that is expressed in the draft comments is one very viable way to go and then there have been some other expressions that go in a completely different direction. One of the expressions that goes in the other direction is that any entity that needs to be -- any provider-related entity that needs to be identified on a claim or in one or the other transactions should get an NPI. Some people believe that this isn't the case and that if we are not able to represent all of those entities with NPIs, that this will mean that the existing numbering schemes that are in use today will have to continue and that this is undesirable.
So, I think the draft comments of the NCVHS -- one thing that is attractive about them is that they establish some very clear overarching visions and it should be relatively easy to determine who gets an NPI and what are the rules for issuing them. But it will leave some entities without identifiers or let's say without standard identifiers and then you would have to still either accept the use of existing numbers for those entities or put off until some later time standardizing that type of thing.
MR. BRAITHWAITE: Mary, can you give us a feel for what those other entities are? Is there some entities' description we can use to get a handle on what they are and why should we be identifying them on a national standard?
MS. EMERSON: I think that the example that you gave with a "pay to" entity, that is one of the common situations where the provider wants payment directed to a certain entity and that entity may not actually be the provider of care.
In some cases, people have wanted to identify contracts by giving them provider identifiers and some existing systems give contracts provider identifiers and --
MR. BRAITHWAITE: Is there a specific location in the standard transaction to identify a contract, like under a contract number or some other mechanism? Why are they using this mechanism for that?
MS. EMERSON: I am not really sure why they are using it. I think the systems have grown up in such a way that they try to give provider numbers to every kind of entity that might need to be identified in the claim that was related to a provider.
The claim -- the kinds of entities that might not be either a warm-blooded person or a bricks and mortar type of provider are the "pay to" entity and, in some cases, a billing provider. Those are the two kinds of entities that might not be covered.
MR. BRAITHWAITE: What is the difference between a billing provider and a "pay to" provider? It sounds --
MS. EMERSON: I am not certain but I know that they are listed separately in the 837 and if they happen to be the same, you don't have to re -- you know, re-identify them.
MR. BRAITHWAITE: It is hard to enumerate or even conceive of a system for enumerating something if you don't understand what it is.
DR. LUMPKIN: It may be, for instance, a two-physician partnership would be a "pay to." Physician B does a procedure. Physician A may own the partnership. The other one is an associate. You pay to that.
Other billing arrangements is that you now send your bills out to a billing service. They get a certain percentage of the gross bill. So, they would get the receivables and then they would write the check to the clinician at the end of the month. So, those would be two different arrangements I could conceive of.
I don't know if that is what intended in the transaction standard.
MR. BRAITHWAITE: The concept of who to send the check to, that is a pretty clear concept and there is already an identification system for that. That one I am pretty comfortable with. The others --
MS. GREENBERG: Yes. I mean, I think the "pay to," you can make a very good case for the fact that -- or some variant of the "pay to," you can make a very good case for it being the I.D., but I am wondering if there are other types of entities, whether there is a sense that a group practice, which under one proposal would get a payer -- I mean, an NPI, I guess, as well as, of course, all the individuals in that practice, whether in some way it constitutes a provider, as opposed to just something you pay to, whether there is some sense of either from the point of view of performance measures or whatever you are looking at, that you would judge providers by these entities do constitute real providers and people have the need to identify them as providers.
I am asking that, rather than knowing the answer.
DR. COHN: I guess as I was looking at all of this, I am -- first of all, I reviewed the NPRM and thought the NPRM did a better job than actually we did. I guess as I look at the issue of institution versus individual provider, now, reviewing our notes from, I guess, a year ago, I find myself a little disturbed that somehow I had let that get through.
I guess in my capacity as a private physician, I belong to the nation's largest group, the Permanente Medical Group, Incorporated. Now, the Permanente Medical Group contracts with a payer, Kaiser Foundation Health Plan, to provide care to a defined population. Now, providers within the group may have specific patients that they either bill or have responsibility for, but there are also patients from a population management view, who may not be assigned a particular provider and are really more the responsibility of the group. So, we need in some way to capture that concept in this NPI.
I thought that considering that groups as an organization is fine. I don't know that we need to, you know, divide them out separately but they certainly need to be captured somewhat.
MS. GREENBERG: Yes. It is my understanding that this principle does not allow for that.
DR. LUMPKIN: Okay. So, what do you want --
DR. COHN: Well, I personally thought that either Option 1 or 2 that was identified by the -- in the NPRM met my requirements. I didn't think that they necessarily need to be split out for a group. They just need to be accounted for somewhere. I think what we are -- all I am commenting on is that our response to -- in our initial letter, we didn't leave that opening for existence of a group. So, do we need to do anything?
DR. LUMPKIN: Well, we have a draft in front of us that we are going to be moving forward in some version to the committee tomorrow.
MS. EMERSON: One thing that occurs to me as I hear you talking about it is that once you start down the road of groups, things get -- easily kind of get stretched and muddied as you get further out from the kind of group that you were talking about and to the point where some people then say you need to give an NPI to every contract or every carve out that any group has.
That sort of gets into a realm of being somewhat unmanageable or could get into that realm.
MR. BRAITHWAITE: Particularly when the legal folks have decided that HCFA has to pay for this under their existing budget.
DR. COHN: Right. And similarly the issue of linkages becomes unmanageable also and I don't even want to get anywhere close to that discussion.
I think I was just really speaking that I think groups, obviously, need to have the option to apply for an NPI. Maybe that is the appropriate way we should think about it.
MR. BRAITHWAITE: There are other mechanisms in a claim to identify the contract that this patient has with their plan and all that. There are lots of other things besides who provided the care.
All Mary is saying is that we have to continue using whatever is being used now for that sort of thing, but not depend on the NPI to identify every possible grouping of providers and their interrelationships.
MR. GELLMAN: Bill, could you -- you just said that HCFA has to pay for this. What does that mean?
MR. BRAITHWAITE: It means the creation of the National Provider System can't be done by a private organization that charges fees for issuing provider numbers, according to our legal analysis and as expressed in the NPRM. Unless we get a supplemental or something happens, it has to be done within the existing budget.
MR. GELLMAN: Is there a written legal opinion on that?
MR. BRAITHWAITE: Yes.
MR. GELLMAN: All right. I would like to see a copy of it at some point.
MS. GREENBERG: Nor is HCFA or the Department allowed to charge a fee. That was also determined.
DR. LUMPKIN: Okay. So, what we have before us is the issue of groups. We have got our draft, which says there isn't a warm body or semi warm body, depending upon the state that you are in, whether it is Alaska or Texas, but -- and you are not built out of bricks and mortars or at least have an address associated with the bricks and mortars location, then you don't get a provider I.D. That is one.
Then we have what is in the NPRM, which is a little bit fuzzy.
Does anyone want to change what we have here in our draft document?
MR. BRAITHWAITE: Kathleen, do you have any input from the insurance point of view that would be useful?
MS. FYFFE: Actually, I would like to compliment you on the way (b) was written because I think you -- I don't have a comment on the (a) principle, but I do have a comment on the (b) principle and particularly that it seems that the two activities of providing identification numbers for providers and enrolling health care providers got confused. And I think you laid that out very well here.
I don't have any comments beyond that.
DR. LUMPKIN: Kepa, did you --
DR. ZUBELDIA: I think the root of the problem is similar to a problem with a payer I.D. The mandate in the law is to have a unique identifier for provider, for payer, for employer and for individual. But there are other entities that are not providers and not payers and they are being forced to fit into one of these two classifications in order to get a number because, otherwise, there will be no number for them.
I think it is brilliant to say the providers would get a provider I.D. The payers will get a payer I.D. and everybody else will think about it later. Maybe there should be another identifier for the rest of health care, clearinghouses and other entities that don't fit into provider I.D.s or payer I.D.s and not force other people to fit into these things.
When you mentioned brick and mortar, there are a lot of situations where a provider will have several offices. Should those offices be identified when they are really not provider? It is place where the service is rendered by a provider. If you extend that like you were talking about contracts, many HMOs and PPOs will have multiple contracts and depending upon what patient the provider has to bill has one I.D. or another I.D., technically because there is no other place to put a number to identify that contract currently. But that can be changed.
So, I think that it is a very good movement, but I would like to see the NCVHS go further and recommend that another identifier, not one of those four, be designed to accommodate those people that don't fit into one of these classifications. It doesn't have to be this year, but there is a need and X12(?) has already started a work group to define something called the EDI, Health Care EDI Identifier.
For instance, clearinghouses and claims processors, like PPAs, PPOs, that are technically not payers would get a number like that just to route transactions. A billing provider, a "pay to" provider that actually endpoint destinations for payment. They are not providers, where the payment is sent and maybe they need to have a routing number associated with them that is not part of a provider I.D.
DR. LUMPKIN: Let's go back to (a) now. We have got (a) before us. Unless someone objects, we are going to move forward with (a) the way it is written.
DR. COHN: Move forward with what?
DR. LUMPKIN: (a) the way it is written.
DR. COHN: I guess I have expressed my discomfort. I am trying to think of on the fly of how to revise it in a way that doesn't require complete rewriting. I guess, let's just ask the question. I mean, does it -- is there fundamentally a strong issue that those around the table feel about having groups somehow captured in all of this.
I am trying to think in my own mind whether I guess I believe whether (a) is true or not. Where they say that the groups, partnerships, corporations do not provide care and it may be that they don't actually provide physically the care, but they are responsible for the care.
Help me on this one. Is that a relationship, which would be ignored because essentially that responsibility is -- has to do with the providing. Is that a --
MR. BRAITHWAITE: I don't think anyone is suggesting we ignore their responsibility or the relationships between providers and those groups. It is just whether or not the National Provider Identifying Number is the place to do that.
MS. COLTIN: And I am sitting here puzzling because I can understand your dilemma, but one of the things -- I could not think of an example where that kind of an entity would actually bill separately from the services that are provided by the individual. The kinds of things I was thinking off had to do with some of the care management activities. We don't bill for those. They are kind of bundled into the provider fee.
Or take a disease management center, for instance, who might be making phone calls to patients to check on compliance with medications or, you know, find out if they were having any kinds of problems or remind them about appointments and things like that, who might not even necessarily be clinical people in every situation, depending on what their function was. It might have gotten rolled up to the level of the vendor, the disease management vendor that was providing the service through a lot of different individual folk, but, in fact, as soon as long as you knew that that was the "pay to" provider, that would work okay.
The question is do you need to then know who was the actual individual who had contact with the patient over the phone, who is the service provider, rendering provider or whatever they are called? And in that case what it may mean is you start enumerating a lot of people who aren't clinical providers, who perform those kinds of services. They are warm bodies. They would fall under your definition, but they may end up representing a group that is somewhat broader than what you have thought about.
MR. BRAITHWAITE: I am told that Medicaid wants to enumerate taxi drivers for the same reason.
DR. LUMPKIN: What we have before us in paragraph (a). Unless I hear a recommendation to modify or just completely wipe out those two sections, then we will move on to (b). I understanding there is some misgiving.
MR. BRAITHWAITE: There was one suggestion about paragraph (a) and that was to add a recommendation that the health care, EDI community come up with another identifier for EDI transaction routing.
DR. LUMPKIN: Oh, the OID.
MR. BRAITHWAITE: The OID, yes.
DR. LUMPKIN: The other.
MS. GREENBERG: I think that was for a difference, EDI purposes, as opposed to what we are talking about here with the group or could it encompass both?
MR. BRAITHWAITE: Well, since the NPI was mandated by an act of Congress, which is oriented towards promoting EDI, and we are taking away some of the current EDI routing function of the NPI by focusing on who provided the care, then the OID recommendation is sort of in that context.
DR. LUMPKIN: So, we would add a sentence on there saying that there may be some entities that don't quite fit in there and we recommend the development of an OID?
MR. BRAITHWAITE: Something like that, yes.
DR. LUMPKIN: Okay.
Paragraph (b). I mean, anybody disagree with OID?
MR. BRAITHWAITE: We are going to have to come up with a better name for it than that.
DR. LUMPKIN: We can make it an alpha one and then it is OIL, other identifying letter.
Paragraph (b). Okay. Anything else in the introduction?
MS. GREENBERG: What did you say before that? Did you say "paragraph (b)"?
DR. LUMPKIN: No one said -- oh, did you want to say something about paragraph (b)?
MS. GREENBERG: Yes, I did.
DR. LUMPKIN: Okay. Go ahead.
MS. GREENBERG: Thank you.
I think a compelling case is made for -- certainly for not turning the NPI into a fully robust research database and I am not going to argue against that. And the distinction between enrollment and enumeration I also think is a useful one.
However, I personally feel this principle has gone a little far and that -- and I am uncomfortable with the National Committee -- this is purely as staff and I am just expressing my view, but making a statement as it does at the end of this principle that further to find the most cost effective mechanism for enumeration, it will also be necessary to eliminate information that would be collected, maintained for other purposes, such as research, suggesting that research is really -- all aspects of research are really like another animal that really are not to be dealt with here.
Although I don't think that I think that a fully, as I said, robust research database can be the purpose of the NPI and I certainly understand the problems you get into with the application of the PRA if you make this too -- go too much beyond the information needed to enumerate and I also think you can be somewhat -- you can somewhat broadly interpret information needed to enumerate and somewhat narrowly, depending on just how many different things you feel a full comfort level at by having to enumerate. I do think, for example, that being able to use the NPI as a sampling frame for research is not an unreasonable expectation.
It is one that the National Center for Health Statistics has had for the last four years, working with HCFA in developing the NPI.
DR. LUMPKIN: So, would you be comfortable with us just deleting the "such as"?
MS. GREENBERG: I certainly would think that the "such as research" is -- I am very uncomfortable with. I don't know if -- I mean, there are other ways in which this principle is articulated also that may, in fact, have the same result and this may be cosmetic, just removing, such as research, but it certainly stuck in my craw. Also, did not really seem -- I felt it was inappropriate coming from the National Committee on Vital and Health Statistics, which has to recognize that health care is often supported by research. It is not just another animal that, you know, shouldn't be bothering us with its requirements.
Now, that is very different than wanting to have -- you know, build this into a big database for research.
DR. LUMPKIN: Okay.
Anybody opposed to deleting "such as research"?
[There was no response.]
Any other problems or suggested wording changes?
MS. GREENBERG: Also to say "eliminate information." I mean, I think we should look very carefully at information that is perhaps not strictly needed for enumeration, but, you know, I think we do have to recognize that, although, yes, every plan has an enrollment, we do -- a process, we do not have a single payer system and, so -- surprise -- and, so, although, yes, everybody has their enrollment files of their providers, this will be the only national provider file that will be for all possible plans.
So, for example, its potential as a sampling frame for national provider studies, by HCFA, NCHS and others, really should not be rejected, I think. That is different than saying -- if you are using it as a provider -- as a sampling frame, you are obviously going to have to go out then and collect the information that I am saying you wouldn't want to collect as part of the NPI. It shouldn't replace those surveys, but it certainly should have enough robustness to be able to be used as a sampling frame.
That might require a few more elements than strictly to enumerate.
DR. LUMPKIN: Let me ask this question. Are we as a committee -- I don't know how quite to put this -- all that concerned about HCFA's budget? Could we just strike that whole last sentence?
MS. GREENBERG: See, maybe this is something the Data Council has to look at and say, look it, this has purposes for the Department and how are we going to help HCFA out.
DR. LUMPKIN: Really, all that last sentence says is we know it is going to cost a lot of money to do this stuff and, HCFA, we feel sorry for you. So, you may have to cut some stuff out. But I think that there is another important point about trying not to link enumeration with enrollment, which is what most of that paragraph talks about.
MR. BRAITHWAITE: Would it be appropriate to replace that last sentence with a recommendation that HHS very carefully look at the cost and benefit of this other information because there are some good uses for it, before they strike it because of budgetary reasons? Just saying the same thing, that is, there is a cost benefit here that has to be evaluated carefully. I don't know. What do you think?
MS. FYFFE: I agree that we have to have some sort of reference to cost and I think that it actually improves that sentence to refer to it as a cost benefit analysis.
DR. LUMPKIN: Okay. Then if that is agreeable, we will modify that sentence. Okay. That will lead in nicely to the next sentence, too.
MS. GREENBERG: You are still striking "such as research"?
DR. LUMPKIN: Yes. It is gone. I mean, research isn't gone, but "such as" is. We like research.
MR. BRAITHWAITE: Okay. Those are the general paragraphs. Then there are a whole bunch of places in the document where the NPRM asks for input and there are drafts of some language based on those two principles in the various places.
There is one particular one I would like to draw your attention to on page 2, where the principle is used as a basis for suggesting a third alternative to either having a sort of independent single entity that does all the registration or enumeration and using the enrollment processes of the federal health plans as a way of getting, say, 80 percent of providers enumerated for the cost/benefit approach.
Karen had some -- it is explicated further on page 6 at the bottom. Karen had some useful information about what the cost savings of going to Option 2 over Option 1 might be. It may require or at least suggest that we change this particular draft comment.
Karen, do you want to fill us in?
MS. TRUDEL: If I am understanding your comments correctly, your assumption is that Option 1 is that all providers would be enumerated individually by a registry and Option 2, that some of those providers would be enumerated by federal and Medicaid health plans.
Your Option 3 suggests utilizing the Medicare and Medicaid data, but also combining that with the concept of a registry. Perhaps we didn't clarify this enough in the NPRM. The first option, which was the registry, was the cost was predicated on using those Medicare and Medicaid files to do the initial load of the existing providers and the registry would be used to enumerate providers after that.
So, there would be a savings by using the existing data. I just wanted to clarify that that actually was part of our intent in Option 1. That being the case, I am not sure how our Option 1 differs from Option 3.
MR. BRAITHWAITE: it sounds like there is not much difference then with the exception of reducing the number of people who get NPIs and reducing the number of people who get NPIs and reducing the amount of information that is collected on each of them makes Option 1 in this case a more viable option, but it might be in the scenario proposed by the NPRM.
So, do we want to just make a statement like that?
DR. LUMPKIN: Let me see if I understand this correctly. We are talking about Option 1, where the provider interfaces with the registry directly.
Option 2 in the NPRM talks about I may interface with the state Medicaid agency, the state licensing agency, which wasn't mentioned, but I thought, perhaps, could have been and then they would then interface with the service, which would significantly reduce the interface that would be required by the centralized registry.
So, one option has a direct user interface and the second one there would be an intermediary that was doing some other sort of enumeration and validation process anyway.
MS. TRUDEL: I think to be a little bit more specific, the Medicaid plan in your example would not be an intermediary. They would not be in the middle of the process between the provider and the registry. They would actually take on the role of the registry for the purpose of that provider, so that the registry and any enumerator would use the national provider system.
DR. LUMPKIN: But the system would have to adjudicate sound alike, look alike, seem alike request for enumeration.
MS. TRUDEL: Right. And that information would go back to whoever the enumerator was.
DR. LUMPKIN: So, if I were an Option 2 state agency, I would get the request for a name. I would submit it to the system and the system would say you can give the number or the system would say, hey, wait a second, this person already has a number.
MS. TRUDEL: Right.
DR. LUMPKIN: So, they really aren't the enumerator. They are the facilitator of the enumeration because the number doesn't get assigned until they get adjudicated through the system. So, it is actually a central system that is assigning the number.
MR. BRAITHWAITE: Well, the system is just a computer program.
MS. GREENBERG: The system is not the registry.
MR. BRAITHWAITE: No, the system is not the registry. The system is the computer program. It contains the database that all enumerators would interact with, including your Medicaid program.
MS. EMERSON: And that system does generate the number.
MS. TRUDEL: But it also contains the logic that will tell the person who is dealing with the provider that they are a potential duplication.
MS. FYFFE: What happens, let's say, if Dr. Lumpkin needs a provider identification number and he treats both Medicaid and Medicare patients, where does he get his number from?
MS. TRUDEL: Whichever one he wants.
MR. BRAITHWAITE: But since they both use the same database and the same computer program to do it, presumably they won't be able to get two numbers.
MS. FYFFE: Okay.
MS. GREENBERG: I guess I need a little clarification on what Karen said. What you were saying was your Option 1, which included the registry, which is just to use the registry, did not have people who were already Medicare providers interfacing directly with the registry.
MS. TRUDEL: That is correct.
MS. GREENBERG: Because that data was going to be loaded in because as you explained it, John, I think, everyone was interfacing directly, but -- so, what is the real difference with Option 2. Do the Medicare and Medicaid plans actually take on some of the functions of the registry?
MS. TRUDEL: That is right. The people function, the handing out of applications, processing of applications, keying the data, working with any potential duplications, that would be the registry's function in Option 1 solely or shared by the registry or by the other enumerators in Option 2.
MS. FYFFE: Okay. So, in Option 1, you have got various administrators of the registry. Okay.
MS. EMERSON: Really, I think that is Option 2, isn't it?
PARTICIPANT: I think that is what she said.
MS. EMERSON: Okay.
DR. LUMPKIN: Okay. So, our revised proposal would be to --
MR. BRAITHWAITE: To reconsider the cost/benefit of the single enumeration function versus using all the federal programs based on the fact that the cost of running the registry under our recommendations would be much less because there are fewer people to enumerate and there is much less data to use when they enumerate, on what the NPRM proposes.
DR. LUMPKIN: Okay. Since we scoped it down, it ought to be cheaper. Okay.
MS. TRUDEL: My question was is the Option 1 in the NPRM the same as the Option 3 that we are proposing here and if it is, then perhaps there doesn't need to be a comment.
DR. LUMPKIN: I think that if there is a comment it would be as I remember reading the NPRM, it did only say "Medicare." I don't remember it saying enumerated from Medicaid.
MS. GREENBERG: Oh, it says "Medicaid"?
[Multiple discussions.]
DR. LUMPKIN: Okay. Never mind.
MS. EMERSON: The way that I understood Bill there in your revision of the comment, I thought that you were proposing that you still make the comment that Option 1 is preferred and the reasoning is that now that the data are, you know, shaved down and so forth, it is reasonable to do that. Okay.
MR. BRAITHWAITE: Many of the specific comments that follow we have essentially already discussed because they are based on the two --
DR. LUMPKIN: Then why don't we just see if any members have comments on the draft, on the sections.
I just have a question while people are doing that. On page -- the pages aren't the same -- it looks like page No. 3, where it says, "By the same token, an individual who is a nurse may become a physician. Here, again, the need for a different identifier is not apparent."
I looked at that again and I didn't go back to the NPRM. So, maybe someone can help me. If there are individuals, who are nurse paramedics, in one venue they are functioning in a pre-hospital setting. In another one, they are operating in a hospital setting because they have they have two jobs.
Is the database that we have robust enough to say that this person is a nurse and a paramedic?
MS. EMERSON: Yes, it is. It allows for multiple iterations of a classification, that is.
Just to go back to one question earlier about the taxonomy and how that would be used, the taxonomy that was referred to earlier is extremely robust. It has almost every kind of provider you might imagine in it, but that doesn't mean that we have made any determination that all of those entities would get NPIs. The taxonomy was developed for a general purpose and it is being used for the NPI, but it doesn't mean everything in there gets an NPI.
MR. BRAITHWAITE: There is one statement in the draft on page 9 that wasn't covered by the principles and that is about new and revised standards, where the Secretary is asking about a waiver process to allow people to develop and test new standards. The draft comment says that we urge HHS to consider having the process for evaluating proposals for new standards rest with a private sector organization with public sector involvement, as opposed to having HHS set up that process, as was suggested in the NPRM example, that actually set up some rules and have a private sector organization do that.
Any comment from the committee about that comment?
DR. LUMPKIN: It looks like everybody is comfortable with that.
MR. BRAITHWAITE: All right. The next section talks about the PRA, the Paperwork Reduction Act. And on page 10 in the middle, essentially the conclusion, the committee urges that -- I guess it is an urge -- I can't tell if it is HHS or OMB, but urges them to follow the intent of the PRA and HIPAA by not applying the Paperwork Reduction Act of the development of these national standards.
Any particular comment on that one?
[There was no response.]
MS. GREENBERG: Can we go back a few pages under "Data." I think we are on page 8, middle of the page, where it starts with "Detailed information." Again, I wonder if
-- I mean, if we can't soften that a little, such as we discussed doing with the principle, so that parsimonious -- I mean, that is fine, but, again, that there would be a cost/benefit analysis or, you know, rather than just saying only those data elements necessary for --
MR. BRAITHWAITE: This is where the principle got applied. So, we will apply the softened principle to this specific recommendation.
DR. LUMPKIN: Okay. We are going to reduce the Paperwork Reduction Act.
DR. MC DONALD: Just a clarification. There really has been yet a proposed set of data elements. There was a database floating around at one time, but that is not part of this.
MR. BRAITHWAITE: The NPRM has a whole layout of database, every element in it, what elements would be private, what elements would be publicly available and so on.
DR. MC DONALD: Well, it sounded -- but the discussion here about whether we should keep a lot or a little bit, has that already been decided then in terms of the proposed database?
MR. BRAITHWAITE: No. What our recommendation says is don't collect all this data for purposes of enumeration. Cut it back to what is -- after a cost/benefit analysis, what is more appropriate for uniquely identifying providers.
Any other comments from the committee? That is sort of the key points that I thought there might be discussion on.
DR. MC DONALD: The identifier will be -- will have no knowledge in it; that is, so you will not distinguish a nurse identifier from a physician identifier by the code.
MR. BRAITHWAITE: That is correct. It would appear as a random number.
DR. LUMPKIN: Unless you know them personally.
MR. BRAITHWAITE: Let's move on to the draft responses to the NPRM on standards for electronic transactions, HCFA149P.
There was much less and maybe no material in here that I thought might be controversial. I will point out a few things. We didn't have any specific principles to lay out before this, just a few specific comments.
On page 2, there is a reference to the WEEDE(?) recommendation about implementation of time frames, that payers who are always capable of forcing providers to send them information in whatever format the payer wants it in were told by WEEDE to not force anybody to require these standards in the first year, even though there is a legal two year compliance time frame. WEEDE is suggesting that even the payers should not force the providers to use this stuff in the first year and that they give their providers at least six months notice before requiring them to use the new standard.
The NCVHS recommends that this implementation schedule be incorporated into the final rules if there is legal authority to do so to reduce the uncertainty and ease the transition period for all segments of the health care industry. If this goes beyond the authority according by HIPAA, we urge HHS to identify other mechanisms to accomplish this objective.
It is my understanding from the legal folks that, in fact, we don't have a legal basis on which to put this particular statement in the final rules. Is that your understanding as well, Karen?
MS. TRUDEL: I believe that the exact concern was that it was premature to do that in the NPRM and that once we had comments from the industry, we might well -- if the comments were overwhelming, we might well suggest that in the final rule given that the Secretary has the general authority to implement these standards in a manner that is efficient and effective.
So, the answer is "maybe."
MR. BRAITHWAITE: So, maybe we should just say we support this or would you like to keep the preexisting wording? It does give her the out there if it turns out she doesn't have the authority.
DR. LUMPKIN: I thought that was very well worded.
MR. BRAITHWAITE: Okay. Anymore comments about that?
[There was no response.]
On the next page, the subject of UPNs, which are, you know, the universal product numbers or like the universal product code that is on your cereal box, the NPRM suggests that the HCFA HCPCs(?) codes would be replaced by UPNs over some period of time. I don't remember exactly what the schedule is. I just wanted to point that out and to see if everyone agrees with that --
DR. MC DONALD: The C codes I know, but -- is that the UPC codes?
MR. BRAITHWAITE: It is essentially the same as UPC, but they call them UPNs when it is applied to -- this is not NDC codes, which is for drugs. This is for --
MS. GREENBERG: Betsy, can you come to a microphone.
MS. HUMPHREYS: My recollection of the NPRM was that we were asking for comments from people on what they thought was an appropriate timetable for implementation of UPC, but wasn't -- the NPRM was not making a statement about that fact. Am I right, Karen? Yes.
So, you would be commenting not do you agree with what the NPRM said because the NPRM didn't make a statement. It just said we have been hearing a lot about UPNs and we would be interested in comments from interested and knowledgeable parties about what would be a reasonable -- whether it was reasonable to go to UNPs, UPCs and when they thought that would be a reasonable thing to do.
MR. BRAITHWAITE: The comment that is in the draft is sort of, yes, we are going to watch this and we like the idea.
MS. HUMPHREYS: Oh, okay. I thought you were saying, yes, we agree with what you said and I was saying we didn't take a position.
MR. BRAITHWAITE: I was bringing it up because we didn't take a position seriously on this and wondering if anybody wanted to take a stronger position one way or the other on it.
MS. HUMPHREYS: Oh, sorry.
MR. BRAITHWAITE: Apparently not.
Okay. In the next paragraph we talk about the local codes. The NCVHS believes that the elimination of local codes, when coupled with an expedited process for establishing new codes, on a national basis it should say, is essential to achieving the goal of administrative simplification and we recommend that HHS provide the resources to establish and support the infrastructure to replace local codes with permanent national codes that meet the business needs.
I know there is some controversy in the industry, particularly from the payers' perspective about whether whatever mechanism we set up can possibly be fast enough to get -- to replace the function of local codes, which are now set up by payers.
I would like to hear from anyone, who has a comment about that and we should explore the potential suggestion of, you know, replacing local codes with a sort of short term temporary code mechanism or something that would allow this transition to happen a little better.
DR. MC DONALD: What is the universe of codes when you are speaking of local codes?
MR. BRAITHWAITE: Essentially it is HCPCs, but it is HCPCs that are made up locally because there is no HCPC code to describe what it is you are doing. The majority of HCPCs codes, in fact, are drug codes.
MS. HUMPHREYS: The majority of locally developed ones are.
MR. BRAITHWAITE: The locally developed HCPCs that are drug codes and those are all going to be replaced under the current mechanism with -- and those are the J codes. Those are going to be replaced by the NDC codes, which are readily available on the drug packages now. So, that takes care of most of them.
But there are still others. You know, we give a certain device to a patient and we have to make up a code for it because there isn't one right now.
DR. MC DONALD: But this paragraph doesn't have to have that constraint on it. I would have thought this could apply to lots of kinds of codes.
MS. HUMPHREYS: Maybe it should say procedure code.
MR. BRAITHWAITE: Well, maybe we can tighten up the reference back to the question in the NPRM about a local code. It is HCPCs level 3 or -- 3 is what we are referring to.
DR. MC DONALD: Who requires that they make up -- what is the driving force? We don't make up CPT4 codes. Why do these device codes -- who wants them?
MS. GREENBERG: Isn't this primarily Medicaid that uses these local codes?
MS. HUMPHREYS: No. I believe that the issue is that payers have particular things that they want to know about what they are paying for and if new devices or new drugs are suddenly available and suddenly they become important for Medicaid/Medicare patients. The payer wants to be able to review and so consequently the fact that they can't enumerate this drug or they can't enumerate this device becomes an issue to them and they need to enumerate it.
You may know more than I know about it.
MR. BRAITHWAITE: Stanley, can you help us out?
MR. ATKINSON: Stanley Atkinson.
Actually, the state Medicaid programs use a significant number of local codes for -- some of them for reimbursement schemes, some of them for some of the waiver program services that they come up with that are outside the normal scope of Medicaid. So, they feel like they need fairly quick turnaround on any request for local codes.
Some of them have stated that they process about 40 to 50 percent of their claims using local codes and that is beyond drug stuff.
MR. BRAITHWAITE: So, do you have some suggestions then about language here that would help them meet their business need without promoting the use of local codes for everything?
MR. ATKINSON: All that they have stated is that they need, I think similar to what you have already said, fairly rapid turnaround, that we need to be able to provide a code to them, you know, probably within 30 days of a request.
DR. MC DONALD: They still have this time frame. It comes up in other contexts. Nobody dies if that code doesn't happen, right? And almost all of these needs develop over three to six, nine month periods. I mean, I have -- you know, we have seen Medicaid response in the other direction is never 30 days.
So, I mean, everybody -- I think what it is, everybody wants to be free to do whatever they want to do when they want to do it and that is sort of a -- and that is good because this is America, but it is not good for standardization.
So, it seems to me that a 30 day response is -- if you don't want it to just be a pile of junk, the code system, that is, if you don't really care what it is. You are just throwing it in and assigning a code, it is okay, but if you want to deal with equivalence, this is the same thing they are -- which is sort of the purpose of not having a local code. Then somebody has to do some research on it and ask them a question or two maybe.
Betsy might be able to comment on just regular medical words and how that problem comes up. I don't think we should just roll over and say we have to instant emergency codes for non-emergency realities, necessarily.
DR. LUMPKIN: So, are you comfortable with this paragraph the way it is written?
PARTICIPANT: You want instant immediate response, don't you, John.
DR. MC DONALD: We want to get rid of them. It doesn't say anything about how fast you will respond.
DR. LUMPKIN: Was that a "yes" or a "no"?
DR. MC DONALD: Yes.
MR. BRAITHWAITE: So, the sense of the committee is that we leave the draft the way it is.
Marjorie?
MS. GREENBERG: Yes. Not on this but on the -- since we are leaving the coding area now, does the committee want to reiterate any of the past recommendations, particularly about supporting the standard coding guidelines or is your policy to only comment where a question was asked? I mean, in the sense of anticipating comments that might come in on the other -- not supporting these standard coding guidelines because it, again, doesn't allow the flexibility that payers currently have and use quite a bit -- I don't know. Maybe I was just thinking in terms of the recommendations you made in the past and also the concept that unless you say it in the context of the NPRM, it sort of is past history.
DR. LUMPKIN: Okay. We will put that in there somewhere.
MS. FRAWLEY: Let me just make a comment also and follow up. Do we want to break out our last sentence about the unified procedure coding framework?
DR. LUMPKIN: Which last sentence?
MS. FRAWLEY: It is on page 3, the last sentence under the local codes.
DR. LUMPKIN: In addition, we really --
MS. FRAWLEY: Yes. It just doesn't really -- I am just wondering if we should break that out because we are really talking about something a little bit different.
DR. LUMPKIN: Okay. It reads, "In addition, we reiterate our willingness to work with HHS and other organizations toward the development of a unified framework for coding procedures."
MS. FRAWLEY: It is really a separate point and I think that we probably should break that out. I am wondering if we should reiterate some of our previous recommendations in that area because we had a specific series on criteria.
DR. LUMPKIN: Well, we could combine that with the issue of the unified coding guidelines.
MS. FYFFE: I have one comment.
I think the first sentence needs to be softened and I will help you with that.
DR. LUMPKIN: The first sentence of that paragraph?
MS. FYFFE: Yes. It says, "Local codes that are required and changed at will by health plans represent one of the most burdensome aspects of current practice that fall upon health care providers."
DR. LUMPKIN: I thought that was restrained.
[Laughter.]
Okay. You want to work with Bill?
MS. FYFFE: I will work with you, Bill.
MR. BRAITHWAITE: All right. Under "Enrollment" there is the issue of the 834 transaction, the enrollment transaction. The committee has before mentioned that they feel that the information like demographics on patients should be collected and transmitted, using the enrollment transaction and not make that information collection something that happens at every claim.
So, the recommendation here is to ensure that demographics are available for use with claims and encounters for research, we urge HHS to take a proactive stance to encourage employers, sponsors, private health plans, et cetera, et cetera, to adopt the 834 enrollment transaction and to make it available under stringent safeguards for legitimate research purposes.
MS. COLTIN: I would like to suggest that we go even further than that. I don't think that the issue of encouraging employers and sponsors to comply with this is limited to the research function. Right now, my understanding is that even for a business transaction, sponsors are not necessarily compelled to comply with these transactions.
So, essentially you have defined a transaction, which originates with an entity that is exempt from the requirement. So, it really becomes a voluntary standard in many ways and I would like to see us push actually for that not to be the case.
MR. BRAITHWAITE: It is only as voluntary as the payers allow it to be.
MS. COLTIN: My read of the law was that an employer --
MR. BRAITHWAITE: The law doesn't comply sponsors to use this transaction. It only requires that the payers accept it, but the payers can require for their contracts with their sponsors to send information in this form.
DR. LUMPKIN: As long as you give me the right information and the dollars. I don't know.
MS. COLTIN: I don't know. In these contractual relationships, the parties are not always equal. You are talking about --
DR. COHN: I also live in Kathy's world. I am struck, obviously -- the legislation doesn't allow us to require sponsors to do it. I agree with you that we want to encourage them to do it. I wish that any of us were in a position to do other things than to ask, help, encourage the sponsors to go by these standards. I don't think we are in a position where we can require them to do it.
MS. COLTIN: Well, and I am not suggesting we do that. I am just saying that the sentence that says that we take a proactive stance on this issue not be limited to the use of the data for research, that it also applies to the use of the data for business purposes.
MR. BRAITHWAITE: Do you want to just take out the word "research" then and say "for legitimate purposes."
MS. COLTIN: Or you could say "business or research." I mean, I don't care. But I just don't want it limited.
MS. GREENBERG: Yes. Actually, looking at the very first sentence, you could say, recognizes the demographic information is very important to many types of -- to health care provision and research. For example, if a plan is required to give culturally competent care and you don't know what the ethnicity of the person is, then it is hard to make those arrangements. So, that is, I guess, a business need. So, maybe just expand that first sentence and either take out "research" here or put that purpose in that other sentence as well.
Does that make sense?
MR. BRAITHWAITE: It makes sense. I just don't quite know how to change the words. If you will help me with that, we will do something there.
DR. LUMPKIN: So, we are going to say something along the lines of health care provision and health care research and then the last one, where we say, "Under stringent safeguards for legitimate --
PARTICIPANT: Business and --
PARTICIPANT: Business and research purposes.
DR. LUMPKIN: Business and research purposes.
I am not sure that businesses will be understood by everybody who reads that. I think, just legitimate purposes.
MR. BRAITHWAITE: Okay. I didn't have anything else in here marked up as something that might be controversial or needs more input.
DR. LUMPKIN: Any additional comments? I had one.
We mention in here a couple of times about giving long term care a break because they are not automated. My understanding is with the new MDS and other systems that are coming in place that long term care is beginning to at least have the hardware that one would think that they would -- now that they have got the hardware, they can do that. So, I am not as inclined to give them a break.
MR. BRAITHWAITE: So, we should harden the long term care statements?
DR. LUMPKIN: Yes. And they still always have the option to do it by paper. They don't have to play, but if they play, they ought to play by the rules.
MR. BRAITHWAITE: Okay.
MS. GREENBERG: Where are we?
DR. LUMPKIN: It is in two places. Page 1 and the top of 2 and then there is someplace else that it pops up.
[Multiple discussions.]
Oh, okay. So, it is in the other document.
Any other comments on it?
MS. GREENBERG: Are we talking about the entire set of comments or just --
DR. LUMPKIN: Yes.
MR. GELLMAN: I have a question. I can't let this PRA language go by a second time without asking about this. I am looking on page 7 and the italics says, "The question arises whether a regulation that adopts an EDI standard used to exchange certain information constitutes an information collection subject to the PRA." Isn't that a legal question?
MR. BRAITHWAITE: As I understand it, the Office of Management and Budget has the legal ability to interpret the application of the PRA rather broadly and this is a case where under that interpretation they could go either way. They could say it applies or they could say it doesn't apply and the NPRM actually asks the question and says should it apply, what do people think, because it is not a clearcut legal decision.
MR. GELLMAN: Well, there has got to be a legal standard somewhere. There could be a legal standard that says the law applies to a whole bunch of things and OMB has the discretion not to apply it in some cases. I mean, I haven't looked at this part of the PRA for a long time. So, I don't have it in my head.
MR. BURKE: My name is John Burke.
I think the primary question is is this an information collection, is the requirement to use a standard in information collection in and of itself. And there has been argument as to the applicability in that is the requirement to use the standard collecting any information or is the standard an analogy that has been used when you fly in U.S. air space you must speak English. There is no information collection, but merely the requirement to use a standard.
With the EDI environment this question has been tossed around. So, this would be a precedent and nobody has approached it. So, at the given time, OMB is soliciting comment on it because they want public input before there is a decision made because the way the rules read under a definition of an information collection, these NPRMs are not mandating an information collection, were to be more specific, a third party disclosure, but merely saying when you disclose the information of a third party, you must use a standard or this language.
That is the question.
MR. GELLMAN: All right. That helps some. I will think about this.
DR. LUMPKIN: Other comments on the prior response?
MR. MC NAMARA: I have a comment. I am surprised that we haven't discussed -- I am Tim McNamara from Multim(?) Information Services -- I am surprised that up until now we haven't discussed the issue of the NDC nomenclature system. That is a nomenclature system that I find, at least, to be somewhat controversial and one that I think needs consideration from this group and potentially others.
It is a very problematic nomenclature system for drugs for a variety of reasons that I think are certainly worthy of comment, but I would propose that the subcommittee think about changing the language or at least encouraging the Secretary to change the language of the NPR to talk about development of a drug nomenclature system that is defined as a drug coding system, which supports multiple levels, kind of abstractions of drug information, including therapy, class clinical drug, manufactured drug products and not limit that to an NDC system, which is focused primarily on drug packaging and much more granular issues of nomenclature than what many providers, physicians, nurses and even pharmacists may need.
I think that is a topic that we should address and I would be happy to discuss and I think we should discuss some of the specific problems with the NDC system.
DR. LUMPKIN: I don't think that we got any of that during our hearings that we conducted.
MR. BRAITHWAITE: No, we didn't.
DR. LUMPKIN: I think that is new information. What I would encourage you to do is to submit that as a comment to the NPRM. It would be difficult for us as a committee to do that without getting more detailed information than what you are able to give today.
Any other -- Marjorie.
MS. GREENBERG: Under new and revised standards, 5, starting on page 5, the NPRM basically lays out two options. One is it gives a number of principles that would have to be followed by -- well, the first comment by the committee is that although the Secretary should be the final arbiter, the committee urges HHS to consider having the process for evaluating proposals rest with the private sector organization with public sector involvement.
I personally didn't have any -- I wasn't going to comment on that. I don't know if anyone else wants to, but then it gets into basically the two approaches, I guess. One is laying out a number of principles that would have to be followed by any of these data content groups and the alternative would be to require an organization, which desired to be designated by the Secretary as the official data content maintenance body for a particular transaction to meet the ANSI criteria for due process found at their Web site.
I printed out their Web site and I have to acknowledge I have not had time to review it in detail, but what isn't clear to me is whether the current groups that maintain data content -- and I am not saying right now whether I think they should continue to or not, but such as the National Uniform Billing Committee and the National Uniform Claim Committee could qualify under these ANSI standards for due process and criteria if they limited their membership as they currently do.
I mean, they have a specified membership, as opposed to anyone who wants to join can be a member. They try to balance primarily the providers and the payers and they have added some other groups, but they -- and this is aside from whether they need to hold open meetings. I think some of them already do and others have acknowledged the need for it and to review comments, but would they, in fact, have to be open to membership by any persons who are directly and materially affected by the activity in question, which is the criteria here under "Openness."
MR. BRAITHWAITE: I think, if I recall correctly, the ANSI standards for due process have three different mechanisms that can meet those criteria and one of those allows for a balanced voting membership for particular purposes. It doesn't require that anybody who wants to join can join and vote. It only requires that the meetings be open and anyone who wants to comment can comment, but the voting can be balanced by design.
I think they would if they had more open meetings, they could qualify. That is my impression anyway.
MS. GREENBERG: You don't interpret them as requiring open membership?
MR. BRAITHWAITE: No.
DR. MC DONALD: There is an openishness that is required because I know NEMA(?) doesn't have ANSI tools by some mechanisms.
MR. BRAITHWAITE: Who?
DR. MC DONALD: NEMA. I mean, I think -- there is some level of openness. That doesn't mean everybody -- you can have a committee with 500 people on it necessarily. I don't know how that balance works. The truth is that any of the ones I have had much to do with, if someone has applied and had to have any kind of argument, they have not resisted. They do sometimes raise the membership fees enough to hold down the numbers.
MS. GREENBERG: Well, it does say something about not making it financially impossible, but I mean these other -- these current groups certainly do not -- they have quite limited membership.
DR. LUMPKIN: I don't see our comments being on whether or not they should. We are just suggesting that it should be a much more open process. So, I am trying to -- in this discussion, do we want to make a comment that we should continue to allow NUCC to, and NUBC, to exist, even if they can't meet the ANSI standards?
MS. GREENBERG: I don't know. I mean, I think the -- kind of my interpretation of the first approach was that it kind of allowed that because it says -- it requires that there be open meetings, at least x number and I think it -- that was the way I read it, that it allowed these groups that -- or the ADA or NCPDP or whatever, to continue to be the content experts if that were decided to be, you know, what was decided, without being -- having, you know, completely open membership.
DR. LUMPKIN: Right, but I am trying to figure out --
MS. GREENBERG: And that by going to the second approach, the ANSI one might not permit that.
DR. LUMPKIN: So, you are disagreeing with what we have here in our draft and saying that we should more strongly favor Option 1 as opposed to Option 2?
MS. GREENBERG: Well, I mean, I can see the advantages of going to Option 2, but, to me, it upsets the apple cart considerably more than Option 1.
DR. LUMPKIN: Okay. Option 1 -- let's see if we have it here.
MS. FYFFE: It is on page 5. It says, "One approach may be as follows:"
MS. GREENBERG: Yes, right towards the bottom of page 5.
DR. LUMPKIN: Option 1, "Each of the data maintenance bodies has biannual meetings with the public welcome to attend and participate without payment of fees. These public meetings are announced to the broadest possible audience at minimum by means of a Web site. Announcements of the meetings may also be available via widely read publications, such as Commerce and Business Daily or the Federal Register." Widely read. Okay.
[Laughter.]
MS. GREENBERG: It must have been written by government bureaucrats.
DR. LUMPKIN: "Annual public meeting schedules are posted on the Web site, not later than 90 days after the effective date of the final rule and annually on the date thereafter. The data maintenance body establishes a central contact, name and post office and e-mail address, to which the public could submit correspondence. During these two open meetings the public has the opportunity to voice concerns and suggest change.
"Each data maintenance body drafts procedures for the public to follow in regard to its meeting protocols. Each data maintenance body drafts procedures for the public to submit requests for data or for revisions of the standard. These draft procedures are easy to use and are adequately communicated to the public.
"Each designated data maintenance body is also responsible for communicating actions taken on the requester and the public, in addition to communicating any changes made to a standard. This may be done via e-mail, mail, publications or a newsletter, but at a minimum are published on a Web site.
"Each data maintenance body responds definitively to each request it receives no later than three months after the request is received."
That was all Option 1.
Option 2, "An alternative approach would be to acquire an organization, which desired to be designated by a Secretary as official data content maintenance body for a particular transaction to meet the ANSI criteria for due process found at their Web site.
"Not only would these criteria meet the intent of HIPAA to advocate an open, balanced consensus process, but once an organization met these criteria, it would be able to apply for ANSI accreditation if so desired."
Our comment basically says we like Option 1.
MS. GREENBERG: No.
DR. LUMPKIN: Oh, Option 2. That is right. Our comment says basically we like Option 2.
DR. MC DONALD: Does that mean you agree with the statement that says it should be ANSI accredited and ANSI -- all those rules?
DR. LUMPKIN: That is what our statement is.
MR. BRAITHWAITE: Not ANSI accredited, just following --
DR. MC DONALD: I understand. I worry about that for what you are describing as -- I mean, I am assuming a lot of the data table creation -- because, firstly, much of the data -- historically, the data table creation has not come from standards bodies, ICD9, CPT4, whatever you want to call it, and it is not clear that those kind of bodies can necessarily produce those kinds of changes because you can't have all the process and the balloting going on every -- if you want to have some reason -- even if 30 days, 90 days response to table. So, I just think that although the direction is -- I support it sort of with my heart. I worry about it with my head.
MR. BRAITHWAITE: Didn't SNOMED just apply for ANSI accreditation?
DR. MC DONALD: Well, the ANSI process is pretty complicated. I mean, it is good, but it implies -- I don't think you are going to -- all of these kinds of things typically put things out with a year to two year cycles. There is not example of 30 day, 60 day, two day, five day responses from standards organizations. Almost by definition it is supposed to have a review process and then people are going to complain and then there is -- there are all these cycles and if you are doing that word by word on a table, it is quite different than arguing about sort of some major data structures or strategies and how it does the messages.
So, I think I would hesitate to endorse that without some better experience with what is -- secondly, is -- I guess that is the main thing -- the second thing in the body they are talking about have everything interconnected, although is attractive from one perspective, there is some real attraction in having specialized areas be able to develop semi-independently their own areas. Like ICD9 and CPT4 are not connected. Now, I don't want to get into arguments about all that, but NORS(?) NDC or even Multim or any of these -- you know, the drug databases, they are not connected. They don't really have to be connected because they apply to different fields.
Now, there is a whole issue about purposes and all the rest that I don't want to get into. So, I just say in general to make a blanket rule, we may end up finding ourselves getting stymied because the processes required are somewhat different in terms of generating vocabulary and codes than it is for generating data structures.
I don't know if Betsy has any or someone else has experience on it, but I know of no examples of a formal standards body keeping up big bodies of data content, at least in an attractive way.
DR. LUMPKIN: I am trying to frame your discussion in the task at hand, which is to pick Option 1 or Option 2 or neither or just not to comment on that. Would you be in agreement with the language that we have before us or are you suggesting that it --
DR. MC DONALD: Well, I think I am worried about the social experiment is, I guess, what I am saying, is to try to get this all done and do this experiment at the same time is -- has me a little nervous and I don't know if I love both -- I think if I had to choose, I prefer Option 1 because it allows a longer -- I mean, there can be more experiments of all kind of organizations can accomplish this and achieve this.
I would like to hear other input, though, because I may be the --
MR. BEATTY: Gary Beatty, Mayo Foundation. I co-chair the Health Care Task Group with NX12. We had our meeting, I guess, a week or so ago and we had a lot of discussion revolving around data content committees within our meetings in the management group.
One of the key differentiations between, I think, what Marjorie has talked about is how does an organization develop consensus versus how does an organization have open meetings. And who actually defines what that consensus process is?
As we looked at the three currently named data content committees out there and all of the other possibilities -- and I agree with Clem's statement that there are a lot of other potential organizations out there, even as we go beyond just the pure health care world and we get into things like worker's compensation, we get organizations like the IAIBC and others that may not want to be ANSI accredited organizations or want to adhere to the rules and the time frames that are involved with the ANSI standards process.
It is a restrictive, long drawn out process and I agree that we have to have the ability to be able to experiment with this thing and be able to create solutions that are more responsive to the whole industry. One thing that is lacking in all of these data coordination things that we talked about at the meeting was that if we go forward with all of these data content committees out there, that they don't all function as little islands in the world of health care and that there has to be some type of coordination that occurs amongst all of those organizations.
In a couple of weeks at the Health Care Informatics Standards Board meeting I am going to bring up that very subject of coordination. Bill and I had talked last week about this issue because we made one proposal and moved it forward at the meeting with one of the HHS people about, you know, just the sheer importance of that coordination effort because if -- from the public's perspective coming into the system, if they have to have a data request, where do they go in this world of all of these islands? Do they go to one? Do they go to all?
How do they hold their meetings together so they get their intent and business needs met? Where if we have one coordination organization managing this whole process as far as the starting point, at least that way the public has an easier time dealing with this whole data content issue.
Thank you.
DR. MANN: Douglas Mann from Batelle Memorial Institute.
As a member of the ANSI accredited INSIGHTS LA(?) Committee, we are having to at this moment manage the HUC(?) codes, which is a national standard for hydrologic units, bodies of water, river basins, et cetera. And it is not a process in the ANSI arena that lends itself to quick and easy revisions. Most of these standards process within ANSI is for longer term, slower moving things. So, for some of these code sets, another avenue is probably a better method for quickly changing and evolving code sets.
DR. LUMPKIN: So, would it be a fair statement to say that we believe that a mechanism needs to be adopted that allows a more timely review and recognizes the changing nature of these standards developments and while we like No. 1, we think that there may be some parts of it that are too restrictive. Is that what I heard?
MS. GREENBERG: I think it is No. 2 that is seen as too restrictive, the ANSI --
DR. LUMPKIN: I actually think No. 1 may be too restrictive. That is what I heard Clem say.
DR. MC DONALD: The thing is we don't know what the commercial side is going to be doing on these things. We don't know -- it is a little bit early for code sets to know what is the right way to go, except that we would like to get one for the different categories of use. That is, if you are going to have this -- Field X should have only one code set in it. Some will be done by the standard organizations. Some will be done by professional organizations. Some will be done -- and we have got to just kind of hope for harmony or push for harmony.
MS. GREENBERG: Okay. But Option 2 or approach 2 is even more restrictive than approach 1, right?
DR. MC DONALD: Right.
DR. LUMPKIN: Clem, can I ask you to, perhaps, work on some language for tomorrow? And then maybe at lunch we can sort of spread it around the committee.
DR. MC DONALD: Yes.
DR. LUMPKIN: Because what I hear, I hear we are kind of -- I don't hear anybody disagreeing with Clem that we need to be -- we need to have some control. We need to have some openness but we also need to allow some more development to occur in a more time frame, but I think we need to kind of put that down on paper and let people have a chance to look at it.
DR. MC DONALD: At some point, I need to be clarified on what I am supposed to be -- what is the box I am reading from.
MR. BRAITHWAITE: I will work with you on that, Clem.
DR. ZUBELDIA: Kepa Zubeldia from Envoy(?).
I would like to point out that the data content goes way beyond the code sets. The code sets are very important part, but there is also the requirements, what data elements are required, what are not required, what constitutes the set, for instance, for an eligibility transaction or for a referral.
For some of these other transactions that are not under the domain of the NUBC or NUCC or WEEDE. So, there are some of them that are strictly under the domain of X12 and maybe there should be an inclusion of X12 into that group of three and let them decide what is their domain and maybe NUBC and NUCC will decide on -- concentrate on the claim and WEEDE may concentrate on eligibility and referrals and let them decide what is their domain of expertise in the data content.
DR. LUMPKIN: Bob.
MR. MAYS: Well, I can't let a meeting go by without talking about MediData(?) Registries. There are actually international standards developed for a framework within which this discussion and this process can take place. That is the ISO11179 and the ANSI X3285 on MediData Registries and on registry operations.
Certainly, the idea of registering of value domains, which is what we are really talking about in the code sets, is one that is gaining a lot of attention not just in health care but across other domains as well. So, it is not simply a matter of looking at the organization and the organizational structure and the specific value domain sets. There are mechanisms to build a framework, which allow a discussion of the harmonization issues in a structured, focused manner.
DR. LUMPKIN: Thank you.
Other comments on the document?
DR. COHN: John, just a question. Am I presuming that we are coming back tomorrow during the breakout to review some of these comments?
DR. LUMPKIN: Actually, the schedule of the meeting has these as something to be presented to the full committee at 1:30 and then we break out at 2:30.
MS. GREENBERG: So, you mentioned lunch?
MR. BRAITHWAITE: So, we have to do this tonight and over lunch tomorrow.
DR. COHN: Or can we ask them to change and have this be at the end of our breakout.
DR. LUMPKIN: There is nothing at the end of the breakout that day.
DR. COHN: That is my point is that we break out at 1:30 and come back at 3:30 or 4:00 to --
MS. FYFFE: We reconvene late in the afternoon.
DR. COHN: Do we reconvene late in the afternoon?
MS. FYFFE: That is what we are suggesting.
DR. COHN: That is what I was suggesting, yes.
MS. GREENBERG: I know that the Subcommittee on Population Specific Issues requires the full 2:30 to 5:00 and possibly in some discussions they have had the last few days, to 5:30 time here for their breakout session. They have an agenda. So, I don't -- unless you want to come back at 5:30.
DR. LUMPKIN: I don't think we are in a position to reschedule the full committee meeting.
DR. COHN: That is well said. Okay.
DR. LUMPKIN: So, I would suggest that we all get together over lunch to finalize this.
We are only an hour behind schedule.
Agenda Item: Preliminary Steps Toward Development of a Framework for Procedure Classification Systems
Okay. Preliminary steps toward development of a framework for procedure classification systems.
MS. HUMPHREYS: In your grand scheme of things, this is --
DR. LUMPKIN: This is Betsy Humphreys.
MS. HUMPHREYS: Sorry. I was looking at your agenda and I don't know which of these is more important. This is, perhaps, a slightly longer term agenda item than the claims attachments. So, I am going to try to go through this. There is a set of handouts that is going around to the people at the table, but I am just going to remind you first, although, obviously, Kathleen remembers perfectly, and it was referenced in your statement, what do we mean by a framework for procedure classification, this was a phrase that was coined in my memory either by Kathleen or Simon or a combination of the two.
So, I am going to review very quickly, based on my own listening to the hearings and to the discussion of this and other groups about this issue, what is -- what we mean when we talk about this framework and what problems were brought before the Committee on HHS about -- that people would hope such a framework would solve and then what are we going to have to do to establish it. And I am going to focus on one aspect of what we have to do, which relates to some work that the National Library of Medicine is trying to get under way in collaboration with some other parties following up on some suggestions that were made at the CPRI Terminology Conference way last November at this point.
So, what is it? This is one opinion, that a framework for procedure classification would provide a coordinated but not necessarily centrally developed -- that is, it could be developed by multiple groups. But it would be an interrelated set of control vocabularies and procedure codes that together would support detailed clinical documentation, statistical reporting, billing, quality assessment, research and anything else you could possibly think of that would need procedure coded procedure data.
It would also provide a mechanism for automated conversion of the vocabulary that is used in clinical documentation to whatever level of codes were needed for statistics, billing or other purposes.
People like the notion of such a thing and while it is being developed or this framework is being put together, they want it to solve numerous problems that are currently being experienced with procedure coding systems. And just to run through rapidly some of the highlights of the problems that have been presented here and elsewhere that we look forward to at the procedure coding framework solving; inadequate coverage of non-physician procedures, duplication; that is, we have more than one code for procedures done in different settings in the current systems that we are using.
Difficulty in relating the hospital and physician data for the same episode of care because the procedure coding systems used for the two things are difficult to relate, even if you know that it is the same patient, which we assume some method of individual identification will solve that one. Right?
The fact that the current systems having been developed for various statistical and billing purposes provide inadequate detail for clinical documentation and then there are numerous production and distribution problems or complaints, I guess you could say. Some of the or nearly all of the current systems that are in use and if you turn this around and say what would people like to see in the future in terms of how coding systems for procedures are maintained and distributed, they would like them to be developed in an environment in which there is full participation by a range of licensed providers; that is, all the health care providers who are represented in the development of these, that there is an open development process.
This gets right back to the previous discussion and I think that the key items that I have heard are -- and some of them in the some rooms here -- that essentially anyone can make a proposal, that the rationale for the decisions about whether proposals are accepted or rejected is somehow published. I mean, you know things were in or out and that the meetings are open.
And I suspect myself that you could propose greater openness or a standard of openness in procedures without getting to the ANSI level, which I agree with Clem and the gentleman who commented here, could provide some level of problem. Of course, everybody wants timely updates and they all have their own meaning for what that is, as Clem pointed out.
Another issue that has come up is the need for sort of published uniform prices or at least pricing algorithms for the network use of the electronic versions of these systems. Since most of the systems were developed in a -- in essence for the paper environment, there tends to be very reasonable and well-known and easily accessible price information for the hard copy. When you start going after the electronic version, particularly for your region or state or multi-hospital system or 40 allied provider groups or whatever, then the Web sites just tell you here is the number to call to negotiate.
I have heard some concern about that issue and that there should be some open information about how these prices are going to be determined and what are the determining factors. And then, of course, everybody wants this to be at incredibly low cost, no cost would be best of all, at least in terms of the comments we have heard.
There is no agreement that we heard in this room or that I have heard elsewhere about which, if any, of the current systems that are available are the best starting places for this new -- this procedure coding system of the future. We have heard numerous suggestions, including the fact that some of the specialty systems that have been developed to cover nursing and other areas would have to be incorporated into this, that CPT would be the best -- revised CPT would be a good place to start, that the ICD10PCS, which has recently undergone its initial testing, maybe that is a good one. And I think that is on your -- is probably going to be on an upcoming agenda to hear a report on that, what happened about that.
Then SNOMED International and there, I am sure, have been others mentioned that I didn't bring up. So, I think that there is the question that has also been raised by people as to whether the framework notion, which is that you have a set of presumably mutually exclusive and interlocking systems addressing different levels of this procedure, whether that is a good idea, or whether what we ought to have as a single system developed by a single responsible entity, that addresses all the levels and wouldn't the latter be easier?
I think that you can look at it practically and politically, that the framework notion that includes a set of related vocabularies is quite attractive from both political and a practical step. Clem alluded to the fact that you might make progress faster on various pieces than if you were trying to do the whole thing in some big single approach. Maybe, maybe not. You could debate that.
There is the technical issue of is it technically feasible, practical, effective to use a set of related codes and to rely on automated procedures to convert data that was captured at a more detailed clinical, granular level into a higher level of aggregation for statistical or billing purposes.
It is this issue of looking at whether that is possible that it seems that you can address that issue, do some testing of that proposition of whether it is possible to do this or not, by using the current systems that we have in use. In fact, at the November CPRI meeting, many participants from all sides of the question, including the clinical system developers, expressed a great interest in having there be an official workable mapping between, for example, SNOMED International and billing and statistical systems, like CPT and ICD9CM.
It is this issue of attempting to see if we can develop a good system for automated or semi-automated -- it will be semi-automated mapping between these levels -- is the question that NLM has been looking at, how we would approach it and what would we need to do to make this happen. And there are two aspects of this. What do we need in order to make this work in a semi-automated, automated, semi-automated fashion and as we determine that, what does that tell us about the characteristics of both the detailed vocabularies and the codes, the characteristics they would have to have to make this work more effectively.
That, of course, you would hope, if we could get the data, would inform the transition toward this new framework, which many would like to see. So, NLM's take on this is that we need at least three different things in order to support automated mapping. One is a basic data map that says, okay, if you find this for this detailed clinical term in the patient's record, what are the potential either diagnosis codes or billing procedure codes that it could map to.
In addition to that, however, because as any of you who have ever looked at this in detail will know, for any given clinical condition or procedure, there generally -- or for many -- there are more than one potential appropriate code. That is why we have a lot of educated people doing the -- in coding in medical records. What is the appropriate code is dependent on a whole set of other factors, which in looking at it, we say, oh, you will have the basic map, which is in automated form and, in addition to that, you will need a set of decision rules. And the decision rules will have to (a) identify the additional data elements or pieces of information that are required to make the appropriate choice and then will have to actually have a set of "if then" statements; you know, if the patient is male, this is what you do; if the patient is female, this is what you do.
So, we have the basic data. We have a set of machinable decision rules that identify the data elements that need to be consulted and what to do with what values in those data elements. Then, of course, we will need a clinical information system that is capable of using the rules and the map.
If you look at where we sit today, what of these three pieces do we have, well, we don't have any of the three pieces, but to borrow an expression from Clem, at the basic data map we know how to do it. This is one of Clem's favorite sayings. We know how to do that. This is the part we don't know how to do.
We know how to do the basic data map. The characteristics of how this should be done have actually been extremely well laid out by a national health service in Great Britain in a Reed System Technical Report, latest revision, January 1998, an excellent piece of work. They cover this extremely well.
We actually have a place to put these maps and, in fact, part of them or sort of a partial map between what we are interested in already exists in the unified medical language system, Medical Source, and the rest of the map could, in fact, be there, be put in there, created there and distributed there.
Now we get to the decision rules. We don't have these. The Arden Syntax Standard, which is now under the aegis, I think, of HL7, may be the applicable standard for defining the rules and exchanging them. But we definitely need research and development to define and test both the format and the content of these rules.
And an international standard for the format and content of such rules would be a highly desirable thing once we figure out what it should be because it would allow clinical system developers to have an approach that worked internationally.
MR. BLAIR: Betsy, I am a little lost here. We were talking -- you were talking about mapping.
MS. HUMPHREYS: Yes.
MR. BLAIR: And then you got on to Arden Syntax.
MS. HUMPHREYS: Not for the mapping but for the decision rules about how to make the selection among alternative choices.
MR. BLAIR: Okay. So, you had switched subjects.
MS. HUMPHREYS: Sorry.
MR. BLAIR: That is okay. I heard you say decision support but then I -- yes, okay. Thank you.
MS. HUMPHREYS: I think that there is a great value if it is possible to formulate decision support rules for this purpose, than having it done according to some international standard would be highly desirable because as I think everyone in the room knows, once you get out of the United States, there are other procedure coding systems that have to be used in different countries and certainly if I were a clinical system developer, I would not want the rules to convert between the Reed System and whatever the U.K. procedure code to come to me in one automated format and then when I was in the United States to have a totally different format that would help me convert from SNOMED to CPT.
MR. BLAIR: So, you are looking at the Arden Syntax as if it is another code set.
MS. HUMPHREYS: No. I am looking at it as if it is -- saying that we should test whether the Arden Syntax is the appropriate standard for encoding the decision rules that we believe will be required to make the appropriate automatic selection of codes, say, billing codes based on detailed clinical data.
DR. MC DONALD: Many of them are many to many. So, you have got to add some rules in there to get to a unique one.
MR. BLAIR: Oh, okay, because my understanding was that it provided a syntax to do that but that the rules --
MS. HUMPHREYS: No, the --
MR. BLAIR: -- not our kind of individualized and they are shareable, but that the Arden Syntax basically was the syntax format for the rules.
MS. HUMPHREYS: That is right. And the issue is is the Arden Syntax as it stands or would it require some extension to serve properly as the standard syntax for rules for this purpose. I think that that is sort of an answerable question. Then in addition to that, what will be the conventions for laying out this particular kind of rule and that would be, you know, the -- if Arden Syntax was selected, that would be the standard for the transmission of the rules, but you are quite right. Then there would be the effort required to create the actual data in the rules for each set that you wanted to map between.
So, our view is that R&D is needed to define and test the format and the content of the rules and R&D is also needed involving clinical system developers to do an iterative testing of the map and the rules to see if they can, in fact, be used in a clinical information system to achieve the result, which is an automatic conversion from more detailed level to whatever higher level aggregation is required for either billing or statistical purposes.
I think that it is safe to say that there are a number of clinical system developers, who would be interested in participating in such testing if we got it underway. So, to say what we are planning -- our general plan, NLM's general plan for moving forward on this whole automated mapping issue is first to get the necessary buy-in from the vocabulary and code developers that would be involved.
We have had good discussions with the College of American Pathologists and the American Medical Association on this and they are considering it and are going to get back to me soon, I think. We would need to obviously involve appropriate standards organizations and other interested parties, which in this case would certainly include clinical system developers.
We would want to then do some sort of a review and discussion of whether our initial cut on these three level components is really the correct on and if it is or if something else is, get an initial definition of what is going to be included at each of these three levels; that is, at the data map level, the decision rule level and in the clinical information system itself. I mean, what functions would be performed or what data would be handled at each level.
Then we would proceed to go forward with putting the data maps in the UMLS medical thesaurus and NLM would be interested in funding R&D work involving other organizations to develop and test the format and content of the rules and also to test the implementation of the use of the maps and the rules in clinical systems. And our expectation is we probably would have to iterate through this a few times to determine what exactly was necessary to have at each of these levels to make a workable system.
My own view is that this process would probably provide a lot of useful input into several things. One would be the whole issue of how you chunk data in computer-based patient records. The other one would be what characteristics and what degree of conceptual interrelationship there really has to be between a detailed clinical vocabulary on the one hand and a higher level coding system on the other in order to make this automated thing a reality.
I, myself, believe that we probably can devise a framework where this would be possible. Whether we know exactly how to do that yet, I am a bit more skeptical of that, but I do think that we could probably find out sooner rather than later if we pursued this. I am not so sure we would find out fast, but we would find out sooner.
So, this is something that we are hoping to get to collaborate with the vocabulary developers and a number of people in the field to do if the -- you know, depending on how the CAP and the AMA view the matter.
DR. LUMPKIN: Comments?
DR. COHN: Well, Betsy, I think it is a great idea and I -- surprise. But I guess the one question I would have about this -- I am certainly convinced that the issues of mapping between may solve a great number of problems and allow for a reasonable framework.
The only question I have has to do with the areas of overlap. Do you have any thoughts about -- I mean, can those also be handled by this sort of approach since there is, obviously, a considerable amount of overlap in --
MS. HUMPHREYS: Well, you know, if you have a hundred percent overlap, that is in synonymy, then you have a little difficulty. That is, it is a one for one conversion. I think that the more difficult issue is when there is a degree of conceptual overlap and the way the world has been sliced and diced is so different that it is difficult to relate how it has been sliced over here with how it is have been diced over there.
To use my usual -- if we are talking about the same patients and you decide to divide them by eye color and I decide to divide them up by size of foot, it is a little bit difficult to relate those two groups of patients. So, I think that one of the things that doing this will help point out is where there must be a certain level of coordination at the different levels or it just won't work.
I would be very surprised if doing this would not suggest valuable enhancements or improvements at all levels of this; you know, at the detailed level and at the aggregation level and maybe in some cases doing the overlap study will show places where there is -- you know, where there is the greatest opportunity to share resources or to use the same number of resources to cover more things because some of it is being covered, you know, double. We will wait and see.
Of course, I have phrased this -- we are looking at this from essentially the technical side of it and there are, obviously, a lot of intellectual property sides to this as well, but this is not going to solve all of those problems that I described that people want solved because we are going to be testing this relating existing systems and we know that the existing systems have problems not the least of which has been pointed -- I mean, the existing systems that I am talking about mapping, not the least of which is inadequate coverage of some of the procedures are being undertaken now and need to be -- will need to be recorded.
MR. BRAITHWAITE: Betsy, do you see these various code developing organizations using a common set of publicly available tools to do this or each writing their own -- using their own sets of tools to a common database or how would you actually implement this kind of thing?
MS. HUMPHREYS: Well, if we were really going to move forward to a framework where we are relatively sure that we have got different groups that presumably have expertise and interest and what have you, responsible for different pieces of this pie. Probably the easiest way to ensure compatibility and lack of duplication would be, in essence, for them to use the same set of tools and at least to have the ability to -- you know, shall we say a virtual common database if not an actual one. That would be the easiest way to do it from a technical point of view.
There are other ways to do it if what is technically easy is not politically feasible.
MS. GIANINY: Melana(?) Gianiny(?), Alternative Link.
After participating in the vocabulary section of HL7, it seemed to me that one of the key needs of EDI is to package a very broad range of different structures of codes into a messaging format that will work for all parties. And it just seems to me that the mapping if not taken in the broadest sense, at least in the narrowest sense, perhaps, that messaging format could be standardized with UMLS for internal transmission and decoded on both the sender -- or, you know, be sent with the senders coded with a unique identifier from the UMLS and decoded on the other end, is at least a temporary solution to meet some EDI problems that are blocking transmission of information in a standard format and causing a huge cost there in the industry.
DR. LUMPKIN: Thank you.
Other questions or comments?
DR. MC DONALD: This vocabulary stuff is hard. It is really, really hard.
DR. LUMPKIN: I am sorry, Clem. I couldn't understand your words.
[Laughter.]
DR. COHN: Betsy, I think I have one final question which is that is this likely to start happening in your view and is there a time frame, work plan or otherwise?
MS. HUMPHREYS: I am -- as I say, I am expecting to -- maybe the message is in my e-mail today. I am expecting literally this week to have our next iteration back from the CAP of AMA, discussion about some of these issues. So, depending on where we are with that, if we are converging on agreement about how to proceed, then I would suspect that NLM would try to move ahead with this fairly rapidly, but the next step, I think, is to discuss this model with the range of interested players and make sure that -- you know, get it modified in light of other bright people thinking about the issue and then move ahead on the initial two things, which would be to work on the data map, just become part of the UMLS development, but get a serious group coming up with a draft proposal for how to instantiate these rules and then, of course, we will have to have some people after that is reviewed and we get some decent thinking on that and think we have something that is workable, then there are going to have to be some groups try to do this, you know, and stantiate them and then there is going to have to be some groups try to make use of the whole package in a clinical system to see if they really come out with something that is workable on the other end.
DR. LUMPKIN: Jeff.
MR. BLAIR: I really feel like the mapping is needed in today's world. I think a lot of the code set vendors are probably, you know, very grateful that the National Library of Medicine would go forward with this. And I am not sure that I have a full understanding of this. So, this is a question because I am fearful about something and I would just absolutely love to be wrong on this.
So, maybe you can tell me that I am and I would be very happy. My feeling is that when you are mapping, if you wind up mapping a code set like SNOMED or DICOM(?), a clinically specific code set, and right now in order for there to be greater usage of these clinically specific code sets, they have to map to the billing systems, ICD and CPG codes.
When they do so, you lose some specificity and I am hoping that we are looking at this as an interim stage, an evolutionary stage, because essentially what we are doing is at least -- I am not able to visualize how we could move from something that is less clinically specific to something that is more in the mapping. I could see it just going the other way. So, it seems to me like what we are doing is -- maybe as I am talking here I am sort of switching my perspective here. I am becoming more optimistic.
Do you view this as a transition stage where it is going to enable the more clinically specific code sets to at least type the billing system, which means that they get into greater use and then over time eventually we migrate more and more to the clinically specific code sets?
MS. HUMPHREYS: Well, let's put it this way. I am not assuming that we are capturing data at the more clinically specific level and then throwing it away. I am assuming that that data is being retained as part of the patient record system, the clinical information system.
On the other hand, my goal is that we could test the hypothesis that we can take that detailed data and at least semi-automatically, without a whole other human intervention step, convert that to acceptable billing and statistical codes, which in my opinion would probably also then become part of the official record. You would know what you had billed for at that level of generality and you would know that you had reported to the health department that this was a case of cholera at whatever level of generality was appropriate, based on the coding systems that were used for that purpose.
When you look at masses of clinical detail, which, of course, many of us have and mostly in paper records, but, you know, when you look at the masses of clinical detail, you can easily understand that for some future purposes even, having a more statistical aggregation of some pieces of information about the patient may be useful for a number of purposes, even if you have not thrown away the clinical detail.
One of the things we haven't determined yet, and Clem makes this point as well, is we really don't know yet how much clinical detail we want to save over time. It is probably more than we get saved now in a claim. It is probably less than that -- you know, the 55, you know, inches of paper if you are a person who has had diabetes for ten years and a couple of complications.
MR. BLAIR: Or a hundred, yes.
MS. HUMPHREYS: So, I think that we don't really know what to say there, but as far as I am concerned, the issue here is can you capture at the clinical level and then also serve these aggregate needs, which probably won't go along because I am not so sure that it is going to make sense to send on for a lot of transactions, where the care is relatively routine, the payment for it is relatively routine, whether we really want to send on masses of clinical data. Maybe we don't, but that remains to be seen.
I am not converting this data to throw away the detail, though. I am converting it so we also have this level of aggregation. We have kept the detailed data, at least in my model of this.
DR. LUMPKIN: Thank you.
Speaking of sending on clinical data, let's move to claims attachments.
Agenda Item: Standardizing Claims Attachments
We have a cast of thousands. There are a couple of chairs on that end and there are a couple of chairs over on that end.
Is there someone who has an airplane -- we will take you first. Steve, you want to lead off?
MR. BARR: I think there are really two topics that we are here for discussion. One was the issue regarding the stoppage of funding for continuation of the Proof of Concept Project. And the other issue, which was probably a lot more involved and most people are here for is the issue of what data is to be placed into the binary identification segment of the 275 transaction that is going to be used to transmit the information from the provider to the payer.
The issue came up that there are two areas that were being considered at one time for how this information should be transmitted. It was ASCII text or HL7 and you had to either use ASCII text in this transmission or HL7. The work group fought with this issue for a long time and in May 1998, the work group came to consensus that the issue was going to be -- we were going to use HL7 only data in the bin segment.
Now, I can tell you that Clem was there and I was one of the staunch supporters of not using ASCII text until I clearly understood the difference in my opinion now of why HL7 should only be used. But before I make my opinion, I think most of these people here have their own opinion and were brought here to speak upon this subject.
So, I would like them to all have a chance to speak and then I can add whatever else is to it and then I can add, too, the issue regarding the lack of funding. In addition, I think you all received a copy of the option paper that was produced by us for the various options that were made available for consideration for how the data should be displayed in the bin segment and to give you the pros and cons for each of the options.
This paper was discussed on Thursday at the Health Data Council meeting and it was discussed -- excuse me -- that was Wednesday of the past week and on Thursday of this past week, it was discussed at the HIPAA Infrastructure Team meeting. Both groups had input to this and also made comments on this. I will leave those until the very end so everybody can have a chance to speak, if that is okay with you, Dr. Lumpkin.
DR. LUMPKIN: Fine.
Gary.
MR. BEATTY: Dr. Lumpkin, National Committee on Vital and Health Statistics, my name is Gary Beatty. I am here today representing Mayo Foundation and a provider -- one of the providers that was and still hopes to participate on the pilot project for the patient attachments, which as we look at it is currently the sharing of clinical information to support the billing process or as known as claim attachments to support the billing process.
I am going to give just two quick statements on the two issues, one being the pilot project, the second being the ASCII versus the formatted data. The pilot project to us in movement of clinical information is very important to the entire claims process for providers.
Currently, we submit a large number of our claims electronically. I believe right now we are right around -- hovering around 80 percent. We would like to be able to get that higher, but there is one barrier to moving that forward and that is the attachments information that must be included for many payers to be able to adjudicate the claim. So, we find that this was being a barrier to getting ourselves to where we want to be at a hundred percent of our transactions being electronic. I am not saying that we want payers to request everything under the sun as far as information but we want them to have the information necessary for them to be able to adjudicate the claims and be able to pay them in a timely fashion.
We also look to the future of the attachments information moving clinical information as far as the discussions we have had earlier today dealing with the electronic medical record and the sharing of medical information, improving the quality of health care for all stakeholders. We were disappointed when the stop order came through. We were moving forward with the process, even though that we have the stop order in place. We have been working with our Medicare carrier to not directly revolve around this project, but at least setting the groundwork, so that once it does pick up again, that we will be able to start up in a timely fashion.
We also have concerns with the process with the stop order in that the Department, as we continue to go through this whole process with the Health Insurance Portability and Accountability Act, is continually being asked to do more and more with less and less money and to do this properly, we believe that the functions that the Department is being asked for must be appropriately funded so that the quality of services that they are going to be rendering to the health care industry are what is expected.
On the second issue, dealing with the codified information, we looked at the 275. We are very involved with HL7 standards. We look to have information codified. If we are going to be moving this information from one computer system to another, it must be in a fashion that the two computer systems can be able to utilize and manage and possibly route to the appropriate people to be able to process, if necessary, for a human.
So, in light of that, we recommend that that information that can be codified within the 275 transaction be so codified. All other information is not -- that cannot be codified within that 275 should seek another standard, such as the HL7 standards, DICOM or others, to be codified in appropriate fashion and as a last resort go down to the text format when no other codified format is available.
Thank you.
DR. LUMPKIN: Thank you.
Any questions of Gary before he has to leave?
MR. BEATTY: I will stick around for awhile, for about 45 minutes.
DR. LUMPKIN: Okay.
Barbara Redding.
MS. REDDING: Well, he has taken about half of what I had to say and said it. So, I will be briefer.
There are two options that the team has been looking at. One is only HL7 structured information. And the other option would be either/or, the provider's choice. They could choose to use structured HL7 or to use ASCII text. You know, in either case, the team fairly strongly that the right coding system would be to use the LOINC(?) codes, the logical observation identifiers names and codes because they are more specific than the X12 region codes and those were really the two options that they looked at fairly carefully.
We did try and get some advice. I had promised that I would take this and ask the NUBC and the NUCC their opinion. We have not yet heard from the NUBC. The NUCC favors the provider having an option just because they think that would be more user friendly.
I don't think I left anything out. I think between us we got it all.
DR. LUMPKIN: George Beeler.
MR. BEELER: Yes. George Beeler from Health Level 7. I handed out and prepared a rather broader discussion than I intend to go through in any way, shape or form, but uncertain as to where the direction is going, I thought it better to be prepared.
I will skip through it. However, I will do so linearly rather than randomly, so that maybe we can keep going.
Basically, HL7 has been participating with X12N in this activity for the better part of a year and a half. We found that our activities greatly complemented each other. HL7, which had its beginnings in the hospital business is now broadly speaking in a large area of clinical care, dealing with outpatient settings, as well as inpatient,, some federal reporting in support of CDC and others.
The challenge in all of this, however, was how to bring together our -- that is, HL7's -- expertise in the clinical processes, how to bring it to bear on the claims attachment challenge that X12 and the HIPAA legislation presented.
The group got together and asked the question how do we go then from a version of attachments that were in paper to those that are electronic. I would like to direct you, if you would, to page 4, the series of slides having to do with what I consider to be the objectives of the committee's methodology. I think they speak to this point of the ASCII versus the non-identified text.
The key was in terms of quality that there should be consistent attachments where each element is unambiguously identified so that one understand (a) what question is being asked and (b) what answer is being given, that there be a mechanism to provide for data integrity for those data elements where it is applicable so that you can capture such things as units of measure. You can capture the provider. You can capture the date and time if that were appropriate.
Secondly, as several have indicated, it has to be usable and the resulting process that has been worked out by the Joint Committee deals with fundamentally a table-driven model. It narrows down to a single HL7 message to carry the attachment's information within the envelope provided by the X12N, 275 transaction, again, with unique identifiers assigned for each elements, so there is no uncertainty as to what is being transferred.
In this way, by the way, we feel we can use existing software and/or rapidly developed new software in order to make it work.
Lastly is the flexibility, the ability to add new attachments, to add new responses, using -- by defining new sets of codes and within the table structure in order to deal with it.
Next, I would jump you to page 7, the bottom of that, which is slide 14, which is the conceptual. Fundamentally, each claim attachment or each attachment element has its own identifier and an element code. This is the key to the maintenance of this whole structure. That is to say that you understand given a given attachment what elements are in it, elements, if you will, are questions within a form, and answers are subsets of the responses to those answers.
The fact that it is a unique code allows you to these processes together. The remainder of this, I shan't walk through, although I would be pleased to do so for others, except to observe that there is within the initial set of definitions a text message that is available. One can define an attachment element that is a simple ASCII text message if that is desired.
The only energy barrier to using that is that it be assigned a unique code so that you know that is a text for some purpose or that is carrying some form of response. Beyond that, the encoding of it is relatively straightforward.
For those who are worried about HL7 syntax, I guess it would take you to the top of page 10. This is not -- I wish it were -- an example of a text message, but if it were, one needs only to fill in the patient identification information, which you are going to want as part of the attachment in any event, followed by a pair of lines. The one labeled OBX would include the 200 or so characters of free text that is available.
By the way, this is the poor man's version of free text. There are much richer forms within the same structure for specific clinical reports, say, radiology report or that sort of thing.
So, I guess, our belief is simply that the need is met through this mechanism; yet, retains some of the controls that the committee felt valuable.
MS. STAHLECKER: Good afternoon, Mr. Chairman, members of the subcommittee. Thank you for the opportunity to offer a statement on the issue of ASCII as an alternative to HL7 messages in the prospective claims attachment standard.
It is a privilege to be invited to address the NCVHS. I will first introduce myself and some of my background related to this issue and then address the topic.
My name is Christine Stahlecker, one less "c" than is on my name card here. I am the EDI coordinator for the Empire Blue Cross/Blue Shield's Medicare Services Division. I have over 20 years experience in data processing with the last 17 at Empire. I am Empire's representative to the Accredited Standards Committees of both X12 and Health Level 7 and I currently hold co-chair positions within each of those organizations.
As part of the X12 Insurance Subcommittee and Health Care Task Group, I co-chair the Work Group on the 275 Patient Information Transaction. Within Health Level 7, I co-chair the Special Interests on Claims Attachments.
I have been a member of the Proof of Concept Project on request for medical records and attachments and claims attachments. Today, however, I am speaking as a representative of the X12 Insurance Subcommittee, Health Care Task Group, Patient Information Work Group.
Many members of the Claims Attachment Proof of Concept Team are included in this work group. The work currently being addressed is to complete the draft of the Claims Attachment Standard so that the Department of Health and Human Services may consider it for recommendation to the Secretary for adoption under HIPAA.
In my discussion, any reference to "claims attachments" refers to this draft and it is not intended to imply any predetermination of the standard.
A final introductory comment is that I have included a brief list of definitions rather than to explain them throughout my discussion and background information on ASCII is also attached.
The issue of whether or not ASCII text should be considered as an alternative to HL7 messages in the claims attachment has received a great deal of debate. When asked, "Can it work,?" the answer is "yes." When asked, "Should it be considered as an alternative to HL7,?" the recommendation of the work groups is "no."
Pursuing this alternative at this time increases the risk to success of the claims attachment standard recommendation. Concerns with the free format ASCII text are, number one, what is the benefit? There are many ways to move text electronically. Why burden this standard with the multiple methods of expressing text? Why not use the HL7 standard message for expressing both text and codified data?
Number two, the standards developers have not addressed the implications of free format text as claims attachments. Initially, this wasn't necessary since at the August 1997, HL7 plenary session a method of expressing text in an HL7 message was first introduced and accepted by the Proof of Concept Team.
Although in December 1997, the scope of the Proof of Concept test was expanded to include ASCII text in the X12 275, efforts since that time have been focused on the codified claims attachments. The test is not being conducted now due to the stop work order.
Number three, identification of the version of ASCII text being used may be required and it has not been evaluated.
Four, free-format text in other ANSI standards has not been considered. If free format ASCII is allowed, should other free formats, for example, ABSIDEC(?), also be allowed.
Number five, by canvassing some translator vendors prior to this meeting, it was learned that translation processing can be variable. Some packages were processed, the bin content as data and subjected to translation. Others will bypass this process when the content is ASCII text and rely on their file transfer software to perform any ASCII to ABSIDEC translations. Standards for the process are not addressed by HIPAA and presumably would need to be defined in the implementation guide.
Number six, industry experts in handling text, for example, the publication industry, are moving toward more structure for data expression, not less structure. SGML and HTML are becoming de facto standards, although among many, for document exchange and processing. XML is being evaluated to express HL7 and X12 standards.
The point is where is the benefit of building a base of ASCII installations during the start up of the claims attachment standard when the industry is moving rapidly in another direction?
Advocates of the ASCII text indicate, number one, the majority of providers do not have their medical records stored electronically. Those that do use transcription services and may be able to forward text data electronically.
Number two, small providers may not be able to create HL7 standard messages.
Number three, there will be an additional cost and learning curve for providers to implement another standard.
Number four, if Medicare contractors are required to distribute free PC software, will it be required to handle attachments? And if so, it will either need to include HL7 or ASCII text.
None of these points are disputed. However, ASCII text was not perceived as the solution among the members of the work groups. The general opinions respectively were text data from transcription services can be included in the HL7 standard message. Small providers typically use software or service vendors who would offer HL7 capability. The cost and learning curve for any standard is to be expected.
The benefit is having a standard, one and only one way of expressing the data. This recommendation is in alignment with the other HIPAA standards, with the goal to be precise and unambiguous. Medicare will need to assess the position on standards in the free PC software.
Recent progress toward consensus has been made, but commitment is still elusive. During an HL7 work session in May 1998, a vote was taken on this issue within the work group. The result was that only HL7 messages would be used in the X12 275 claims attachment recommendation. Since that meeting, the draft implementation guide describing the X12 and HL7 components was completed.
The HL7 component is now proceeding that SDO's approval process. An open forum was conducted at the June 1998 X12 working session, where it was stated that only HL7 messages would be used in the X12 275 bin. Only one question was raised and that was for clarification, not dissent.
Members representing NUBC and UCC and the ADA were present. The X12 275 additional information to support a health care claim or encounter is now published as a draft implementation guide for preliminary review. It can be found on the Washington Publishing Web Site under "Guides and Development." Comments will be accepted by the work group until August 2nd, and will be addressed in the final draft, expected to be completed in October.
I want to thank you again for this opportunity and I did have this prepared statement, not understanding the informality of today's work session.
Do you have any questions for me?
DR. LUMPKIN: Why don't we get all the presentations and then we will take questions. Thank you.
Frank Serrao.
MR. SERRAO: My name is Frank Serrao. I am from TSI International. We are a data transformation and EDI translator, HL7 translator, et cetera, et cetera, et cetera, company. We were brought here, I guess, to give you some idea, as you can see, relatively late ideas, for me to be here. So, what I have to say is going to be relatively brief.
We actually had a conference call this morning that I was involved in to see what we should say at this meeting and what we really believe is that TSI being a tools company is not in a position to dictate methodology, although, obviously, we know what is happening in the industry and we know some of the "got yous" in terms of making a decision like this.
Certainly, putting HL7, the standard, in the bin segment is from a pure standpoint, from an automation standpoint, from a tying in the applications to the back end -- excuse me -- back office applications are the best solution. The one thing TSI wants to make sure we caution you against -- and I think we are being a little bit unselfish here because we can certainly handle the situation -- very few, if any, besides us, and I am not sure, but I think we are one of the few out there for sure, products can handle an HL7 data nested within an EDI transaction.
So, your small providers are going to be somewhat limited in terms of what their choices are. We would certainly love to have them all come to TSI and use our product, but I think that is one of the really biggest drawbacks of going with the HL7 only solution is that small providers in our opinion are going to have a problem finding products in the market that can handle that particular situation.
That is basically it.
DR. LUMPKIN: Thank you.
DR. ZUBELDIA: Kepa Zubeldia with Envoy Corporation.
We had a very limited discussion about this topic in the last two weeks. So, I am not representing an official position of a fact today.
From the clearinghouse perspective, we don't care. We are going to treat the attachment content as a binary large object and no matter what it is, we are going to move it forward from maybe a pragmatic perspective. Maybe it is not an issue of whether it is ASCII text or HL7. Maybe the issue has other implications.
For instance, what happens if the attachment actually it is a power point presentation or is it an x-ray, dental x-ray? You can certainly put binary objects inside the HL7, inside the 275, but what is the point? Maybe there should be three different types of attachments, ones that can be codified in X12, in the 275 itself.
For example, the certificate of medical necessity, which is today part of a claim and may never go out, but if it ever goes out of a claim, it can easily be codified in X12. In order to be codified in HL7, we may have to go through some contortions.
That second level of attachment could be an attachment and can be easily codified in HL7 or can be easily codified in DICOM or easily codified as a binary file, power point file or something else. That could go inside the binary segment. Those two types would be preferred attachments because they are codified and they can be processed automatically by a computer in order to help in the adjudication of the claim, which is the bottom line.
There may be other attachments that cannot be codified and processed by a computer as such. Those could be an ASCII text. Whether the ASCII text goes inside the 275 or inside an HL7, inside a 275, it really doesn't make much difference as long as we know how it is going to be done. But I think we need to keep in mind that there will be other types of attachments that cannot be easily codified in HL7. They may have to be included in the bin segment as such.
MR. BARR: Since I am the last speaker, I would like to address one issue before I start.
Do you believe that if we do HL7, that there will not be a hue and cry from the small companies to go out and do this kind of work, provide this kind of service to all small providers in this country? If you are the only one who does it now, that there would be a hue and cry for other companies to get into this?
MR. SERRAO: You are asking a market question. At this point, I can't answer. Sure, if there is enough demand, you are going to see products at the marketplace. Will they in a timely enough manner, how long before product -- you know, I mean, there may be issues associated with -- I mean, I know that we handle the technical issues of nesting one standard within another, okay, because our product has been built -- without getting into detail -- our product has been built in a very generic manner. It is not geared towards EDI or HL7, whatever. It is geared towards data transformation.
Most translators out on the market today were built to translate HL7 or EDI or whatever other standard and as a result, they were optimized for those particular standards. Those types of products do what they do very well, but if you try to use them to translate a different standard, they are going to start to break down because they were optimized for one. Okay?
A small provider right off the bat, when you all sit there and say it is time, you know, you are going to have to do HL7 with an EDI now, there won't be a product waiting for them. Well, there will be one.
We have a product that can be used for that. Okay? Maybe other products come out, but it may not be timely enough.
MR. BARR: The only reason I mention that is is in the Impuren(?) that went out earlier, it was mentioned in the NPRM that went out for the transactions that HL7 was going to be considered in the future for attachments and it gave some warning to the industry that HL7 was going to be utilized in the future. That is the only reason I brought that up.
DR. LUMPKIN: What do you mean by small provider?
MR. BARR: It is the small provider to -- how I take the context of small provider that is always mentioned to me is the small provider lives on a mountain in Montana, that wants to do his own work. That is what I consider a small provider.
My rationale is if you are a small provider, there are only three ways you are going to do work in the future environment. You are going to send it in by paper if you don't want to be involved at all. You are going to either have a service process your claims and they are going to take care of all the work for you or if you are that smart and can do the whole cadre of ANSI transactions, which includes the 837 and the 835 and the 275 and all that goes around it, doing an HL7 message with the NA275 is minor.
Either way, even that small provider, unless he is very, very brilliant and does his own internal programming, they are going to have a service that are going to do their billing in the future. So, that small provider is the guy who really is 1 percent of the industry. That is I would partake it.
DR. LUMPKIN: Are you answering that question because --
MR. BRAITHWAITE: I am adding to it because in searching for people to talk to us today, I did talk to a couple of the vendors of physician office practice systems and tried to get them to come talk to us. I talked to some of the people at Medical Managers, one of the systems that appears in many, many small provider offices around the country and their response was, hey, no problem. We do that. We can do that. We will support that.
But --
DR. LUMPKIN: What is "that"?
MR. BRAITHWAITE: "That" is the HL7 message inside, the X12 message for attachment.
His only problem was a conceptual one and that is there are many practice management systems out there that are very small; that is, the company was started by a physician who did it for his own office and then they have got two or three other people in town that also use it. It is those organizations, it is those companies that he was worried would have trouble knowing that now we have to do it with X12 and now you add another standard, the HL7 on top of that.
Although we have heard today that it is only a single HL7 message they have to worry about, not the whole gamut of everything in HL7. So, it is not as bad as he was conceiving, but at least the idea of adding -- in an initial time frame, the extra HL7 message on top of the X12 would be daunting to them. If you could, you know, allow them to do just ASCII in segments for a few years, that would help them.
That was his comment, not mine.
DR. LUMPKIN: Okay. Is this to clarify the issue of small provider?
MR. BEELER: Two comments. I believe there are a number of HL7 participating vendors who will be stepping up to the plate on this. So, I don't think it is going to be only one, but I think Bill said the key thing. It is only one of 70 HL7 messages that we are talking about.
And the other thing that vastly reduces the complexity is that the optionality, which people normally have to deal with in HL7 interfaces has been stripped out under this process. It is a very straightforward, almost linear implementation of one segment -- this is the part I didn't have the time to go through earlier -- that is called for here. This is not HL7 science, if you can use the rocket science analogy.
This is more like walking down the street in terms of creating these messages, creating a simple response from any system would be straightforward. I have been tempted by that same prospect of maybe everybody should get out in the street and make one of these things for small practice systems. I don't think it is that hard.
MS. STAHLECKER: I would reiterate again the small provider in our Empire environment has been identified as submitting a very small percentage of our electronic transactions. We are getting about 58 percent of our Blue Shield claims electronically today. If you look at the direct submits from providers, that is a much lower number, more in the 22 percent range.
However, those electronic claims that are coming in are coming in from practice management systems, less than 1 percent, about a half of a percent, and when you add on our Medicare Part B volume, we are getting about 82 percent of our claims in electronically on the Medicare Part B side. But still, again, this is small physician office. The small physician office is only submitting about 1 percent of those claims. The small physician office, what does that mean?
It means someone who has not purchased a vendor's package and maybe has hired a consultant programmer to come in and develop a small billing package. It is not often that it is a one physician office. Often it is a multi-physician office, but they have banded together to have their billing packages created.
So that, as Bill had pointed out, that type of vendor system may need to be readdressed. It is a far cry to say that systems out there don't exist.
I would like to respond to the vendor comment, too, if I may. The package that we happen to be using, Software Technology's DataGate, does operate on a variety of platforms and handles both X12 and HL7 messages. We find that that product is implemented. As part of our Proof of Concept test, New York Hospital was going to use that same product to send us our transactions.
So, we would very much like to be allowed to continue in our test. The types of transactions -- and I think this gets to yet again another point. Let's get the low hanging fruit, those that are investing in electronic capabilities should have a standard developed for them so that they might begin to use it.
New York Hospital happens to image all of their medical records and since imaging was dropped from part of our test, my test provider was unable to participate in the conclusion of that test. So, here we have a lot of discussion about putting in ASCII text and I think we need to move away from that and start to focus on some more of the more pertinent capabilities in the electronic exchange of information.
I hope I said that so it made sense. New York Hospital is able to submit electronic attachments or medical records are able to come in electronically and we would very much like to continue to test that and prove the bin segment in the 275 is able to process that. That is a very key objective here as part of what we were trying to do in our Proof of Concept test.
MR. BEATTY: Just to further support HL7, we also use a common, commercially available, off-the-shelf translator for our X12 transactions that also supports the HL7 standard. And we are using it more in a PC environment, you know. So, we are running a very low end type of solution that supports both X12 and the HL7 standard. These things are out there. The market will drive more and more of the vendors out there to be able to support those.
I kind of kid myself because I take -- I just got a new laptop this last week and the power that is out there for the small providers, it is like on one laptop I can translate 300,000 health care claims in an hour. So, I mean, the power is out there. There are products out there that are coming out continuously. There is more innovative solutions that are going to come forward as more electronic commerce becomes available across the Internet in a secure fashion for those small providers that don't have any ability to do these things.
I think there is a lot of room for innovation and the combination of these two formats works very well.
MR. BARR: One of the other things I would like to bring up is when we were originally going to do the testing at the five payer locations using the various providers in this country, one of the requirements we made was that every payer utilize a translator that was different, that we did not buy five of one translator type. We made the five payers go out and do homework, do research, go out and evaluate the various translators that were available to them and made sure that none of the five used were committed to the same translator company.
So, before we stopped, we originally had five translator companies in place that were going to utilize HL7 data within HU75 and we were going to test that feasibility.
So, we had already tested the market and evaluated the market and we were going to bring in this whole cadre of actions.
MR. SERRAO: Once again, I didn't come here to defend using ASCII text in a segment. It was just a word of caution. Do these products that you are bringing, just out of curiosity, is it nested? Is it supporting HL7 or EDI or is it nested HL7 within an EDI bin segment?
MS. STAHLECKER: Actually, it does all of the three. It supports HL7 and in this particular case it is capable of taking the 275 with the HL7 content. And that is not -- as Steve pointed out, it is not the only product that we have found that can do that.
DR. COHN: I am really actually not having a hard -- I mean, I think the idea of an HL7, you know, within the X12 is fine. I am just sitting here mulling about it. I mean, we have talked about the small provider as an -- are they going to be okay with this and just thinking back to the legislation and, you know, where that the provider actually doesn't have to send this if they don't want to. So, it doesn't really affect them hardly at all.
I was actually wondering more about the payers, insurers, HMOs, others who are going to be receiving this and I was just observing that I hadn't recently been engaged with any of the payers who weren't on X12 committees to find out really what they were feeling about this and whether this was going to be an issue for them or not. I was just observing that at some point we probably need to get them back in to hear from them regarding the possible complexities of the claims attachment be it the HL7 inside or the other ASCII text.
DR. ZUBELDIA: Let me comment on that.
A couple of years ago, NAIC started a pilot project to do attachments with three of our payers and the three payers were then to take attachments in a proprietary format that we have invented and this was at a time when none of this discussions existed yet. We couldn't find a single provider that could send attachments electronically.
So, I am more concerned about the providers than the payers.
DR. MC DONALD: Just to comment. Chris is a payer and --
PARTICIPANT: [Comment off microphone.]
DR. MC DONALD: She came just for that purpose. The 14 people voted that they -- I think 11 of them had just come -- were payers. So, it is not that this -- this is not an HL7 and Steve can say the same thing. There are actually always more payers in the room.
MR. BARR: One of the things that I would like to bring up is -- and Chris mentioned it in her presentation -- is that this topic was discussed at a two hour open forum meeting in Columbus, Ohio two weeks ago, where the Proof of Concept Team and the X12, 275 Work Group, discussed the entire transaction, discussed the HL7 message imbedded in the 275 transaction, gave out a copy for everybody there, who were payers, providers, vendors, clearinghouses.
There were 200 people in attendance at the conference, where we discussed the entire transaction, the issues that we thought were important. As Chris mentioned, we got one question and one question only, which was kind of frightening because either they didn't understand what we were talking about or we made it so crystal clear that they had no comments. We kind of don't think we were that good of talkers.
The only good thing I can tell you about it is is that the process has now started, where there are 60 day comments from everybody who was there and it goes on to the X12 Web site, where anybody can comment now on the entire process from providers, payers, vendors, clearinghouses, all have 60 days to comment on the transaction, which clearly states, like everybody said, this HL7 message imbedded in the 275 bin segment and that is the only option that is available.
In addition to that, the process is underway within HL7 to have the HL7 portion of the messaging structure that was developed for the sole purpose of having it imbedded in the 275 transaction because the message that is being utilized in this transaction is a more simpler -- if I am not mistaken, Woody can say it in its proper context -- a more simpler and easier message structure, but it meets all the guidelines of HL7 and they did this -- they created this messaging structure for the attachment process only. So, we have kind of got the comment period going out at X12. We have a comment period going out at some point of time in the near future, I believe, Woody, for HL7.
We are ready to accept the comments from both sides, pro or con, for this whole entire avenue.
MS. FYFFE: A couple of comments.
First of all, if the objective of HIPAA or one of the objectives of HIPAA is to increase the amount of automation in the health industry, which of these two solutions, in general, would increase the amount of automation? Do we have an answer to that question?
MR. BARR: It is the group's opinion that the way that it would increase the automation is to use HL7 only, only because it goes one option and one option only. What we didn't want to do was have a provider have an optionality of whether to use ASCII text or HL7 because if you use ASCII text, you are not automating anything. You are taking text that already exists in multiple formats and sticking it in a bin segment.
MS. FYFFE: Okay. I might not have asked the right question because right now, non-automation means paper.
MR. BARR: Correct. A hundred percent.
MS. FYFFE: If the providers can send something that is not HL7 that is going to be a different format and, quote, automate it, that is automation.
MR. BARR: That is automation.
PARTICIPANT: No, that is electronic. It may not be automation.
MS. FYFFE: That is electronic.
DR. LUMPKIN: But I would point out that the purpose of HIPAA was not to increase automation. It was to decrease complexity and to simplify. Those aren't always the same. Just as we have had some prior discussions that we have to be careful about moving towards standardization, if we don't apply the tests first, is the standardization going to lead to simplification?
MS. FYFFE: Okay.
DR. LUMPKIN: It can sometimes increase the complexity.
MS. FYFFE: My concern is that if Option 2 gives more flexibility to the sender, isn't that superior than saying to them you either have to do Option 1 or paper. Isn't Option 2 a compromise? Because then you would end up with more electronic information being used rather than paper. Please listen now. If it turns out that Option 2 is considered the standard initially for a few years, could it not be that the market itself will figure out whether it will be HL7 or unstructured text and at some point in the future, the Secretary could adopt one of those two?
I mean, I am thinking of the greater good here --
MR. BARR: There are two issues.
MS. FYFFE: -- to get people off of paper. That is my concern.
MR. BARR: There are two issues. The one issue is for all HIPAA transactions, whether it is the claim or the remittance or whatever it is, we only give the provider and the payer one way and one way to do it only. You submit a claim this way and this way only. You just do it remittance advice this way and this way only. This would be the only HIPAA transaction where you would have an option. So, therefore, you have taken away the entire structure of HIPAA transactions and now decided we are going to give optionality. That is one.
MS. FYFFE: Okay. I have a comment to make to that.
MR. BARR: Okay.
Two, in ASCII text, one of the problems is there is two kinds of ASCII text. There is unstructured ASCII text and structured ASCII text. If you start doing unstructured ASCII text, then the problem also is the data stream that comes in from the provider, if he has any character identification in the transmission that can stop the transmission, the transmission automatically stops. So, every provider would have to reformat unstructured ASCII text to make sure that the character stream was unique and would not contain any of these characters.
If it was structured ASCII text, the other issue becomes you would now have to make specific guiding questions for every situation, which means that if you had 50 attachments and 50 parts of those, there would only be one way and one way to develop that question, which means you have a structured way to send it in. That means that a provider could only answer the question one way and one way only and somebody would have to develop these structured parameters for every attachment.
That has not even been thought of. We are done. So, one way you have -- the problem is you couldn't use existing ASCII text. You would have to reformat it. And, two, there is nobody or no organization yet that is developing a stream for structured ASCII text for specific questions.
MS. FYFFE: Let me just make one comment about your first premise in that multiple options are inconsistent with other proposed HIPAA transactions. It is true, but right now we have a variety of electronic formats being used for claims and for payments and what the Secretary is saying, okay, let's have one. Right now, isn't our bigger issue with attachments the fact that they are on paper and they are not electronic?
MS. STAHLECKER: -- of our test provider.
MS. FYFFE: Yes. So, I don't see -- I don't personally buy that argument, okay, because it is not the same thing.
DR. ZUBELDIA: Kathleen, maybe one way to solve that is for the payers to accept e-mail. I don't think HIPAA precludes them from accepting e-mail, right? I mean, the HL systems are not going to be shut down by HIPAA, I hope. So, if the provider can and wants to send a structured attachment using the HL7 inside of 275, the payer can adjudicate that automatically. If the provider doesn't have that capability and you don't want the provider to send paper, the payer can say send me whatever you want via e-mail. It has to be processed by hand. It cannot be processed automatically. But at least you don't have paper. And the bottom line is going to be the same as sending the e-mail inside the HL7.
DR. LUMPKIN: I think they can send it by fax. They couldn't e-mail it. I think e-mail would be an electronic transmission.
I am going to go with Gary, then Jeff.
MR. BEATTY: I just wanted to touch back with Kathleen's comment about paper moving things electronically. If you think about -- just pick one type of attachment, like an ambulance report and a payer receiving ambulance reports from a thousand different providers out there, probably all 1,000 are going to look different. What we are trying to achieve is some similarity between those so that the information can be processed in a very consistent fashion, you know, simplification, you know, and just moving that in an electronic format and sticking that in, you are going to take those thousand different paper formats and now turn them into a thousand different electronic formats that the payers are still going to have to interpret.
MS. FYFFE: Well,t hat is true, but still -- providers aren't required to do this. My fear is that they are going to take the path of least resistance and continue to use paper instead of doing something that is not the most elegant electronically. That is my only concern. I am not going to beat this to death.
DR. LUMPKIN: I just have to make one comment, that I think I want to work for your company so I can start off my conversations by saying "In our Empire." I love it.
MS. STAHLECKER: That did get a lot of discussion when they renamed themselves.
There are a couple of points here, the provider not being required to bill electronically. That is very true. And, quite frankly, the structure of any standard transaction set is not going to change the paradigm in that physician's office. It is not the structure of the transaction. It is not how well you write the guide. It is a totally different event that is going to encourage that provider to build their claims electronically.
If they are not building their claims electronically, the likelihood of them sending in their claims attachments is slim. We don't necessarily need to build a pathway for that target audience when we start with our initial HIPAA guide for a claims attachment.
On the point of, you know, getting something in electronically rather than to paper, let's get them off paper, if we were addressing the claim a couple of years ago, we never would have entertained the idea of taking in a free format ASCII data content set. That is about analogous to what we are suggesting here when we say let's take in the claims attachment that way.
It is just illogical to think you can move the burden of processing that information over to the payer side just for the benefit of not having to take a piece of paper through the mail. That isn't what administrative simplification was about.
The true EDI benefit is when we can automate the processing on the receiver side of these transactions and that drives us back toward a more structured definition of the claims attachments.
DR. LUMPKIN: Jeff.
MR. BLAIR: Could I just get clarification?
I think Bobby had indicated that it was the NUBC or NUCC that had indicated that it wanted to retain ASCII text and then, Chris, I think you wound up saying that there were -- those representatives in your last meeting -- could you clarify for me just what the position is on NUBC and NUCC?
MS. REDDING: The National Uniform Clients Committee said that they preferred having the option. The National Uniform Billing Committee has not yet gotten back to us. So, we don't know what their position will be.
MR. BARR: And I think the other issue was that at the open forum meeting in Columbus, Ohio, when we discussed this issue again, there were representatives from the AMA and the NUBC there present and there was no dissenting comment at that point of time. That does mean, again, like I said before, that the transaction itself was clearly understood by everybody in attendance, but they were present at the open forum.
DR. MC DONALD: There has been a tendency for some of the providers, and I think, perhaps, with good reason, to say "no" to anything that makes it easier to get attachments because attachments are, at least, received sometimes as being harassment rather than information gathering. I don't know that that is true, but you hear those rumors sometimes.
So that I think it depends on how the question is phrased, the answer you might get in terms of asking them this.
There is another issue that I don't know if we really want to get into it and that is standardizing the questions because that is the inverse if you want to -- if those questions were standardized in the appropriate body such that harassment questions couldn't be made up or, you know, we could probably come to a better world for both sides.
MS. WARD: Maria Ward, Blue Cross/Blue Shield of Illinois.
Simon had asked a question about 10 or 15 minutes ago about payers and the payers' perspective on all this and Clem answered it actually to some extent, what I was going to say. The work group that Chris was referring to, the Proof of Concept Team, is actually five payers and it was the vote of those payers with one dissenting vote actually to move forward with HL7 only; three Blues, United HealthCare and Exact Medicare Services.
Actually, as we went forward, talking a little bit about what Steve talked about, as we went forward and looked at options for translator companies, it is not like we were narrowed and all of us had to use TSI because TSI is all that was there. We had decisions to make and multiple options to choose from when we went forward. So, I don't think it is a problem for the payer community, at least not from the group that we have representing the Proof of Concept Team.
MR. SERRAO: Even if there are other products on the market, okay, that can do this, the point I guess that -- I am sorry -- one thing I think is very important to look at is that my experience at TSI in terms of rolling out small providers in the industry isn't health care. It was WalMart and IBM and whatever other company out there that was acting like a hub and was telling all of their providers -- in the case of WalMart, the folks that were sending them products to put on the shelves, that they would do EDI. WalMart is very powerful and even the tiny ma and pa shops that were going to put their product -- that were putting their products on WalMart shelves pushed back enough where WalMart came to TSI and said give us a solution.
And what we did is sort of partner together and came out with our product, Trading Partner PC, which is a trading partner EDI product. It is very low end. It is very cheap. WalMart could afford to pay part of the cost for their providers. The providers could afford to pay the other half, whatever they came up with.
But the important point here is that all of those providers were then enabled. Okay? Between WalMart and the provider and us and whoever, a solution was there. Okay. Cloverleaf is a great example. I wasn't aware they had that capability. How much does Cloverleaf cost? It is a quarter of a million dollars or something, isn't it, to roll that product out?
PARTICIPANT: When we looked at them, they were in a price negotiation --
MR. SERRAO: They are a very expensive product. They are not a low end PC product. These small providers may have a PC sitting in the back office. Okay? What they may be doing right now with that PC is generating a report or whatever that they faxed to you folks.
If you want to truly enable them from an electronic perspective, they need the capability to put a low end PC product in those machines and talk EDI with you and then -- I am telling you, HL7 imbedded is the best solution. It truly is, from an automation standpoint. I don't think -- this is my opinion, not TSI's -- I don't think it is realistic for you all to believe they are going to make that jump that quickly. I think you have to empower them and let them evolve.
In order to do that, I think you need some sort of bridge there.
DR. LUMPKIN: Let me, perhaps, jump in here because -- let me see if I can get some summary to what I have heard. I have heard a discussion about small providers but I think what I hear is a clarification is that we are not talking about small providers. We are talking about providers who are using small vendors.
In my wife's office -- and may of you have heard me refer to my wife's office -- she has a large vendor and from what I heard Bill say, even though there are only two docs in her office, those large vendors are going to make that change. What we haven't dealt with is is that we have got 12 transactions coming down the pike that a small vendor is going to have to completely redo their system or they will not be able to send electronic bills.
To what extent are we talking about an incremental increase and what they have to do to differentiate between sending ASCII versus HL7. And it seems to me that we are really talking about a small incremental change to what they are going to have to do to be able to send electronic billing to do all the rest of the X12 other standards that we have already passed.
I think, though, that there is an issue that we haven't addressed in attachments and today is probably not the time to do it. I can't remember who raised it, Clem or Simon, and it has to do with the interchange and the feeling of persecution.
This issue came, I think, really to the fore around a small discussion that was held between the AMA and HCFA over ENM codes. And the realization that I came to -- and we have had some discussion about this in claims attachments -- is that payers ask for claims attachments to verify the code that is sent, to justify or adjudicate code. And the problem is is that it is a system which has no evidence. There is no evidence that I have heard that says that if I send you my record and you review my record, you are going to decrease your fraud.
I think that is an issue that we as a committee perhaps need to address, not today, but sometime in the future, to what purpose and what end and what evidence-based rationale -- I mean, it could be that if we did the studies that if you ask for two pieces of information, two data fields, you can differentiate between the fraudulent claims and the non-fraudulent claims. You don't need to have the whole history and physical.
But given that, our challenge and our charge here today is to really choose between two options. Option 1, which is -- that would require HL7 within X12, 275 bin and the second one, which would allow ASCII text in addition to HL7. That is what we are being asked -- is there some readiness to make a decision on that?
DR. MC DONALD: I have been involved in this thing all along so that I may not be a -- but the problem with ASCII is that it really puts away the step that has got to be there anyway. I mean, it really doesn't do anything and that is the problem with it. It isn't really an option because you have got to put some kind of a new invention on it and it is going to be making up a new standard and it is -- this thing is so teeny. I could have a guy -- what we ought to do is recommend that HCFA or somebody spend a week writing this little program for guys to do this, just this little bitty extra string you got to --
DR. LUMPKIN: I think what Clem said is that he move that we recommend Option 1. I think I heard him say that.
MS. FRAWLEY: Second.
DR. LUMPKIN: It has been moved and seconded.
Is there discussion on the motion?
[There was no response.]
Okay. All those in favor signify by saying "aye."
[There was a chorus of "ayes."]
Opposed say "nay."
[There was no response.]
Abstentions?
MS. FYFFE: Abstain.
DR. LUMPKIN: Okay.
We have one abstention.
So, we will bring this forward to the full committee.
MR. BARR: There is one other issue.
DR. LUMPKIN: There is always an attachment.
MR. BARR: There is always an attachment. To every piece of paper, there is always an attachment. That is the reason we have paper.
It is the lack of funding issue. One of the issues was that when we discussed with this committee in February, we had a target plan of what we wanted to do, based upon the fact we were a fully funded project. That funding has subsequently stopped. At the February meeting, we anticipated to do the 277 transaction in its completion, which was the 277 request for additional information from the payer to the provider and finalize that transaction. We were going to finalize the 275 transaction, which was the response back from the provider to the payer.
When I say "finalize," that means going out, soliciting comments, finalizing the implementation guide, having everything ready to go as a working document. Testing both the 277 transaction and the 275 transaction at five pair locations with ten providers doing a cadre of transactions and would test the feasibility of this transaction because, one, as was mentioned a long time ago by Clem, you have no idea of what attachments really get into and, two, that this was such an evolved process and using such a new concept that we really wanted to test the feasibility of all this before we put it out on the market.
The identification and resolution of all the issues that were going to be brought up during the test period of time, standardizing the selected attachments -- we have standardized two, which are the ambulance and emergency room notes. We are in the process of standardizing outpatient therapy questions. But, again, that is on a voluntary basis, and finalizing the NPRM.
With the stop work order that occurred April 3rd, 1998, everybody involved in the project received a note from HCFA to stop work on this project, which means all the communication that was developed between the payers and providers that were going to do the testing, all that work that had been developed, getting the translators in place and the programming cost and all this literally stopped. Programming contracts ceased. The negotiations with providers ceased. The providers were left hanging and the payers were left hanging.
We had weekly teleconferences for an hour and a half a week just to get this done. They completely ceased. We had three meetings scheduled in Baltimore to work on this project. They ceased. Limited attendance at the HL7 meeting in Baltimore in May and there is probably going to be even less participation in September.
What is going to happen in reality is both the ANSI 277 and the 275 implementation guides are not complete and will not be completed in time. All testing for this transaction has been cancelled. The good will and whatever the work we have done to get this testing done -- and we had some very high profile universities and providers involved in this -- has ceased.
I am not sure if all the participation of all the payers that were involved in this process are going to continue. Some of the payers that were involved are no longer in the Medicare program or will not be involved in this project as we continue, which means we are going to have to create new partners, bring people on board and develop them up to the expertise of the existing staff if we can get them back on with the project.
The work group made certain decisions that will have to be evaluated by the new members, which is not an easy task bringing new people on board where people have spent two years working on the project. The NPRM will have to be written addressing the 275 transactions only, which is only going to be the request from the provider to the payer and that is predicated on work being done by X12 without the Proof of Concept Team, which really was funded by HCFA and there is no funding.
The X12 will now have to do the predication that they are going to do to supply the support to do this kind of work. After the work on the 275 is done, then the NPRM will be written. Then we can start working on the 277. But, in reality, one of the biggest drawbacks of this whole thing is that we originally were going to do testing for this transaction and test the feasibility of this whole entire phase of using LOINC codes and using 275 transaction and using the bin segment and using a new transaction that had never been developed, had never been used, was never used by anybody. We were going to throw it on the table, tell people to use it and now that has ceased.
DR. MC DONALD: Are you asking for renewal of funding?
MR. BARR: We will take funding. As a matter of fact, this is --
DR. MC DONALD: Let us suggest because this follows on another suggestion earlier that we would, well, at least open the question of whether we would encourage HCFA to obtain funding to do this. I mean, there is the whole issue of doing more. I think the chairman brought it up earlier, that there -- they need to do this stuff. We don't want to lose the quality of what you are doing.
PARTICIPANT: We will buy lottery tickets for you.
MR. BARR: One of the things we -- when it occurred we were -- it occurred in April. We were going to test beginning in May. So, that whole cadre of work just ceased at that point of time.
MR. BLAIR: What was the reason given for the discontinuance of funding?
MR. BARR: Discontinuance of funding was that the HIPAA mandate -- HIPAA was not a funded mandate by, I think, I believe, by Congress. I may not get the words correctly done. It was an unfunded mandate and there was no money allocated in this year's budget for HIPAA and, therefore, there was no funding that could continue. The money that was used for the work from October through April was funded from another project -- it wasn't funded from another project. It was funded from X12 support as we were working through X12.
MS. REDDING: We expected -- we had requested funding and it was cancelled. We have requested funding again for fiscal 1999.
MS. TRUDEL: If I could clarify that a little bit, the fiscal year 1998 budget was already well down the road at the time that the HIPAA legislation was passed and by the time we realized what we were going to need to do on attachments, it was even more down the road.
We submitted a request for a supplemental appropriation for fiscal year 1998. That did not make it through Congress. However, when we formulated our fiscal year 1999 request and we have just recently formulated a fiscal 2000 request, we have included funding for the claims attachments and I have no reason to believe that it will not go through.
DR. MC DONALD: Mr. Chairman, should we make a motion to support -- to encourage funding for the HIPAA legislation and related activities? Or since it is already going to happen, we can just claim success.
DR. LUMPKIN: Sure. It has been moved.
MR. BLAIR: Second.
DR. LUMPKIN: It has been moved and seconded that we -- since we only advise the Secretary, that we advise the Secretary that we think that funding for HIPAA implementation is a good idea and suggest that it be in the budget and where it is in the budget, we think that it ought to be supported.
Any discussion?
[There was no response.]
All those in favor say "aye."
[There was a chorus of "ayes."]
Opposed?
[There was no response.]
Okay. Carries. And I have been through those budgetary battles, so I empathize with her.
We have -- thank you -- one final item and that is to talk about the hearings for unique identifier.
Marjorie.
MS. GREENBERG: I just wonder where this leaves the -- because I think this is on the agenda tomorrow as well -- where this leads the subcommittee's recommendations to the full committee and, thus, to the Department, on claims attachments since the February -- the discussion in the context of the February hearing and then I think at the March meeting, too, was assuming there would be -- you know, generally supported the Proof of Concept approach and the development of the NPRM around that approach, et cetera.
DR. LUMPKIN: Well, what I am going to suggest, I don't think we need to report on that until Wednesday.
MS. GREENBERG: Oh, okay.
DR. LUMPKIN: So, when we get back together tomorrow, we can discuss -- I think the issue is is whether or not we want to recommend moving forward with an untested standard. And I think that there is going to be a lot of hesitancy to do that. So, we probably need to have a fuller discussion.
MS. GREENBERG: Yes. I mean, at 1:30 it was comments -- tomorrow -- NPRMs and claims attachment recommendations. You could ask to defer that until -- the second part until Wednesday.
DR. LUMPKIN: Right. And we can bring that up -- there is an item on --
MS. GREENBERG: When you report back.
DR. LUMPKIN: Right.
MR. BLAIR: Will we be learning anything more about if there is any other impacts on limited funding that affects the things that the committee is doing in terms of recommending HIPAA standards? This is the first time I realized that it had affected health claim attachments. Maybe I am just late to know is it affecting anything else that we are doing?
DR. LUMPKIN: I don't know that we have anything
-- Karen.
MS. TRUDEL: The other activities that were affected -- and I will stress that this is in the short run for the rest of this fiscal year -- were some of the development activities for the National Provider System and for the system that would assign payer I.D.s.
Now, those projects had been running with already allocated funds and are still running at this point at a lower level, with previously allocated funds. The impact, I think, on the final timetable and deliverables for those systems will be fairly small as far as we know right now.
DR. LUMPKIN: Okay. Thank you.
Agenda Item: Discuss Plans for Hearings on Unique Individual Identifier
The final item on our agenda is to discuss the hearings on unique individual identifiers. I had suggested that we might be able to move that until tomorrow but one of our leaders in this, Mary Emerson, is not going to be here tomorrow. So, I thought maybe we could at least get this discussion started today and then shoot for -- since we are only about 15, 20 minutes late, for adjournment after that.
So, Mary, if you would like to join us at the table.
Of course, the big question is is that we have hearings scheduled for July 20th and 21st. Pretty much, we have decided whether or not we have an NOI, we are going to have the hearing. That is in Chicago, right? That would be in Chicago in the J.R. Thompson Center.
MR. BRAITHWAITE: We have come up with a contingency plan in case the NOI is not out in time and that is we are going to put together a white paper, which will lay out the issues and the relationship between the white paper and the notice of intent is --
DR. LUMPKIN: Purely coincidental.
MR. BRAITHWAITE: Surely coincidental.
MS. EMERSON: But if you read the white paper, you may not need to read the notice of intent.
DR. LUMPKIN: Now you tell me.
MS. GREENBERG: It has been described as an NOI in a white paper attachment or an NOI in a brown paper bag, I think.
DR. LUMPKIN: Do you have any opening thoughts?
MS. EMERSON: No, I don't. And I will have to say also that the document that you have was put together by other people who contributed to it more than I did. So, I don't want you to think that this -- I don't want to take credit for something that I didn't participate in.
DR. LUMPKIN: Nor blame.
MS. EMERSON: Well, no, I don't have any blame.
DR. LUMPKIN: Okay. We have a series of questions in the documents?
MS. EMERSON: These are basically the questions that are posed in the notice of intent. Most of them are, at least. I think Judy Ball actually worked on putting this list together, taking it from the notice of intent and maybe she would want to say a few words about the question.
MS. BALL: The notice of intent asks far more questions than you have in front of you. This is our best effort to try to pare them down to get to the most essential issues. Unfortunately, or fortunately, as the case may be, it is still a rather long list. The expectation is that not everybody would address all the questions and if they do, hopefully, they will do it on paper.
DR. LUMPKIN: Okay. Could you perhaps walk us through the NOI process and how that is different than an NPRM?
MS. EMERSON: Okay. Well, it is a more preliminary process than a notice of proposed rule making and in the case of the NOI that we have prepared, it lays out a lot of questions and background material that we think would be important in a discussion of a unique identifier for individuals. And it also lays out a number of different proposals that have been put forward for a unique identifier for individuals and tries to look at their pros and cons in a very neutral and fair way. And it does not recommend any particular proposal.
So, that is how it really differs from a notice of proposed rule making. A notice of proposed rule making would be actually making a proposal and this does not make a proposal. It lays out all the options and tries to discuss pros and cons of them, asks a lot of questions of the public and then it, in effect, waits for the public to answer.
What might follow after we look at the comments that we get would be a notice of proposed rule making. The notice of intent will go out for a 60 day comment period just like a notice of proposed rule making and then, you know, we will analyze those comments.
A decision would be made after that as to whether the next step would be a notice of proposed rule making that would actually make a proposal for an identifier.
DR. LUMPKIN: In the NPRM process, HHS is required to respond to all comments, not individually but in the categories in which the comments were made. Is there an obligation to respond to the comments of an NOI or is it just thank you for your comments and now we are going to think about it?
MS. EMERSON: I don't technically know the answer to that, but my guess would be that we would not be required to respond to each comment the way that we are required on a notice of proposed rule making. Maybe others can say "yea" or "nay."
MR. BRAITHWAITE: As far as I know, there is no legal requirement. The response would be an NPRM if we made a decision.
DR. MC DONALD: We seem to be circling this issue at about the same level the last year and a half or so and always proposing these variants with a very neutral stance and worried about the firestorm that might follow from anything stronger.
A couple of things have happened while we have been sort of circling the issue that changed these things a little bit. One of them is there has been a recent kind of high visibility stealing of identities, at least in our city with three people I know, starting with social security number probably, and this is not really a function of weakness of social security number but how various agencies easily give away the rest of your identity when you come in with that number as sort of a master lock, a master key to the whole vault.
The second thing is that the biometrics has just rapidly changed and the possibilities of biometrics has really been very dramatic in terms of low price.
Given those two things, I don't know the answer but I almost wonder whether we could maybe -- maybe there is a new set of solutions that might work. The problem with, you know, these mappings of many different databases is you really don't have good enough keys to do health care with it, not with the ones we have around, except for maybe social security number.
And we have done some experiments with that and you just get too many -- it is good enough for research or statistical research, but if you are going to actually treat a patient based on information coming from it, you could get in deep trouble. But with the biometrics overlaid on top of it, this cross matching could get quite good.
So, I don't know where that leaves us, but I think we need something else besides -- well, we will find out. Maybe we will get something else when we send this out, but I have the sense that we are just not -- no one is going to take a step and maybe there isn't a right step and we are -- but things have changed in biometrics. If you wait long enough, there will be very solid biometric mechanisms for doing this.
MR. BLAIR: Will we have an opportunity for additional hearings in September on the new options? Biometrics is one, master person index has been suggested to me as something that we ought to listen to a little bit more.
DR. LUMPKIN: Those are all in the NOI. It covers all of those options. The intent was originally to have three hearings after NOI came out. We have got one scheduled and I think the intent would be to continue to have three hearings. So, I don't know if we set times and places.
MS. GREENBERG: We haven't. There is a possibility, I think, of having one in conjunction with the September meeting, the September -- was it 15, 16 or --
DR. MC DONALD: The other thing that we haven't clearly identified or articulated is what are the deep level things that we are really struggling with. There are some parties that really want no -- you know, patients have the free right to divide themselves in a million different -- you know, individuals in a -- just like in a bank account, which defeats some of the -- I mean, which is okay but then we don't get any of these other things that we would want to get out of health care. We aren't really digging down deep enough, I think, to really wrestle with what are the deep fears that we really can -- can we get around them? Because some of these solutions -- and I think the master patient index is one of them is just another way to say hide yourself in a hundred different places.
It is tough, but I know that we get multiple registrations all the time in our hospital, even with the real aggressive effort to try to figure out who is who.
PARTICIPANT: It is a fact of life.
DR. LUMPKIN: But actually, what we are going to try to do in the waning minutes of this meeting is not to debate the issue of unique identifiers. It is really to review the questions for the hearing on the 20th and 21st of July, so that we can make sure that we have those and to also identify individuals that we want to invite.
Marjorie.
MS. GREENBERG: Also, I don't think there is any reason why you couldn't specifically, if you feel there is some new information out there or some new approaches that have advanced or old approaches that are advanced quite a bit, to ask individuals representing that to provide testimony at the July 20th and 21st. They don't have to just respond -- in fact, that is part of, I think -- I don't know where but within, I know, the NOI, it says, you know, there are some other things we haven't considered or are there more pros than we have thought of or more cons.
MR. BLAIR: Marjorie, are you the contact point for that in terms of setting up the witnesses?
MS. GREENBERG: I think it would be Judy and Bill and Karen, probably, as the lead staff to this subcommittee, but --
DR. LUMPKIN: I think that what we would like to try to do is to come out with some structure to that hearing so that we can think of -- if we have got two days of hearings, we can -- we have tended to do like a day and a half of hearings and then have half a day for a committee to kind of pull it together. I am not sure we are ready enough to do that, that we might just want to have two full days of hearings and then kind of cogitate on what we had and then think about it and talk about it in September when we have our meeting.
MR. BRAITHWAITE: When the staff got together and came up with this proposal based on our previous experience, to give you something at least to react to. The idea was to take a day and a half and break it up into six panels. Maybe we want to add a panel on biometrics or something now, but the six panels would be one of providers, one of plans -- does this sound familiar -- one of the SDOs, particularly to talk about the various master person index mediation projects that are going on; one where there is a group of people where we are trying to bring together some diverse physicians from the CPRI and from HIPIC(?) and a couple of others that are trying to come up with a more coherent position. So, they will bring up something new that they have come up with based on the previous differences in their positions.
A panel on public health and research, that kind of user of these identifiers; a panel from consumers and privacy advocates to give us the balanced view, hopefully, on some of the deeper issues, rather than just people in conflict. And maybe we can think about adding -- if we don't think we need a full half day to discuss it afterwards, we could think about adding one on the more recent technology for identifying individuals.
DR. LUMPKIN: I think that my concern is -- I think that that sounds like a good -- I just wonder if that consumer group is long enough. I think one panel may not be enough and I think I might be inclined to -- if we are going to add some extra time, add time to that and then in our September hearing, in another hearings, bring in the cutting edge of unique identifying individuals. But this would be sort of a foundation meeting, bring in some of the groups, particularly some of the Chicago-based groups, AMA, those kind of groups and then look for some -- I think we would want individuals from the HIV community, you know, disability community, a whole host of individuals, who may have some concerns.
It would be interesting to see if we can find someone who represents the individual, who felt that they didn't get adequate care because their medical information wasn't available. Somehow, those individuals --
DR. MC DONALD: They don't always realize -- that part doesn't show up. What you might -- how long is the wait to get registered? That is the thing that everybody feels, all that work you have to do because you don't have that preauthorization -- you don't have your gold card or whatever it is -- Hertz gold or whatever the heck -- one of those things. They know who you are and they can process you right away.
MS. HUMPHREYS: Rob could speak to this more than I, but there is the group -- and I assume some of them were the affected people, who were distressed about the fact that there wasn't enough information available about follow-on from the Gulf War, participation in syndrome and the fact that data could not easily be aggregated, even in the systems where theoretically it is easier to aggregate than it does out in the field, I don't know if there is an illustration of that or whether --
MR. KOLODNER: Well, it was a presidential directive that talked about VA and DOD will work together to create a lifelong medical record. That was issued in November. And the Congress has been beating on both VA and DOD because it has been so difficult to put together the information, in part because neither side was automated down to that level of detail, as far as the clinical signs and symptoms and history.
So, putting it together has taken more time and cost more, partially by going back and doing systematic interviews and collecting the data --
MS. HUMPHREYS: I guess it probably wasn't an identification issue really.
MR. KOLODNER: It wasn't identification. It was really at the clinical data level. Both of us use social security number as the core with all of the limitations.
DR. LUMPKIN: Well, I think that we can perhaps look at -- there are -- for instance, we got sued by four families, whose children had neuroblastoma, and they wanted to look at our state cancer registry to be able to identify cases of neuroblastoma in close proximity to coal gasification plant. The unfortunate problem in Illinois, there isn't any location in the state that is greater than 70 miles away from a coal gasification plant that was in existence at some time.
It seems to me that we tend to always get the groups who are opposed to it as being our advocacy groups and I think we need to look at, as Betsy suggested. Maybe some of those groups who would really want to be able to get more information about the disease they are concerned about but feel that lack of our ability to aggregate data is hampering. And I can't think of anyone right at the moment, but I think you may want to cast about.
DR. MC DONALD: Could we think about getting testimony from organizations that have used the universal identifier? I mean, we have got the veterans and the military. That is one. And you have got Canada and you have got Germany. I mean, you have got a lot of countries that have used the universal health identifier and we certainly have some -- the military and the veterans have used social security here and what is the problems they have had with it?
DR. LUMPKIN: I think that is a good idea. I would probably recommend that for a Washington-based meeting because it would probably be easier to get people to come. So, I think we need to add that. We have got two panels now for our September meeting, which is the biometrics and international experience.
MS. GREENBERG: The issue you were mentioning and I don't know whether they have spoken out on this issue or a group such as this, but there are any number of groups representing people with various chronic conditions, such as the American Diabetes Association and going on from there, which have a strong interest in coordination of care for people who have chronic conditions, as well as continuity of care and linking all the different types of care -- what?
MS. COLTIN: Performance measurements.
MS. GREENBERG: Yes, performance measurements, but -- and I don't know whether they have, you know, addressed this issue but they -- we have heard from these groups in the past. They weren't that relevant maybe when we were looking at administrative transactions or financial transactions because they are -- but they are patient advocates -- they are advocates for -- basically advocates in research arms for people with chronic conditions and they might have physicians or might want to think about having physicians in this area.
DR. LUMPKIN: We may want to invite an organization of the homeless. I have no idea whether they are going to be pro or con, but that may be a population who a unique identifier may be of some value.
MS. GREENBERG: HRSA has homeless programs. They would probably be a source.
MS. HUMPHREYS: In sort of a related issue -- and I don't have any idea how they handle this, but I happen to know that Octo(?) Barnett's lab at Massachusetts General Hospital has, in fact, fielded a patient record system, which is used to treat the homeless. You know, they developed this and it has been deployed in the Boston area and I have no idea what they do with this or whether there would be organizations that they worked with to implement the use of the system, who might have physicians on this. I don't know.
I mean, there are probably other illustrations. That was the first one I know of.
DR. LUMPKIN: We have got a million two individuals in our integrated material on child health system, which uses the unique identifier for combination unique identifier, master patient index that we use in --
MS. HUMPHREYS: And there is the Western Governors Association, you know, that are putting in the health passport program, smart I.D. thing. There are some very -- they have had a strong interest in application of technology to health care, telemedicine, as well, but also -- and they are using the health passport also for a lot of the things that you are doing for your populations, John; you know, that they are issuing these to people who get a lot of different types of social services. Some are health services and some are not.
So, they might be a good source of people and also of assessment of how this has gone down within the states that they are or have implemented in.
MR. SCANLON: There are also some states that have taken a few steps in terms of using certain kinds of identifiers. I think Minnesota, we heard from one of the representatives there. He may be willing to come to Chicago, but apparently they were using an algorithm derived from the social security number for most public programs in Minnesota. It might be worth hearing what their experience is.
MS. FRAWLEY: Go through NADO, you know, maybe find out through NADO.
MS. GREENBERG: I guess we should try to benefit from organizations, groups, whatever, that are in the Chicago area and in their broader regional area. I know we have already gotten a few calls from people on the East Coast wondering will we be having another hearing in a place other than Chicago. And we did talk about having one possibly on the West Coast as well, south or another part of the country.
PARTICIPANT: How about the southwest?
MS. GREENBERG: Actually, I don't know about the Western Governors, where they are based, but --
PARTICIPANT: Denver.
MS. GREENBERG: Oh, okay.
[Multiple discussions.]
MS. HUMPHREYS: I should follow-up. Dan Maloney of the VA, who works with Rob, is the person who has been following a whole lot of these smart card developments for seven, eight, now G8, efforts. He probably would know better than anyone else I can bring up off hand, where are the places where they have used the smart card as a unique identification. I think that the Western Governors is the big project, I mean, other than outside of the military, but we already -- so, he may know of others that are closer to Chicago.
MR. SCANLON: John, just to round out, I know that Bob Gellman's group and John Fanning, I was thinking of the folks they would like to see come here as well. Obviously, they have another way to look at it. So, maybe we could -- at the full meeting tomorrow or whatever, reserve some time for them.
MR. BRAITHWAITE: We got a two page list of potential people from Gellman today.
DR. LUMPKIN: Let's then ask everyone -- I think we just got this today, the list of questions.
MR. BRAITHWAITE: I think we sent those out on the e-mail last week.
DR. LUMPKIN: Where was I?
Any comments on the questions?
MS. EMERSON: One thing, I think, that might be helpful just to direct your thinking about the questions is we say there in the introduction that not every organization would answer all the questions, but, nevertheless, the sheer volume of questions, is that offputting?
DR. MC DONALD: You said this was the smaller set, right?
MS. EMERSON: When you really get the NPRM, you have even more questions you can respond to.
DR. COHN: I thought the questions were fine. We may after the first session in July decide that maybe a smaller group is more appropriate, but I like the fact that it handled the technology and sort of identifier issues, as opposed -- and the privacy and confidentiality all together.
DR. LUMPKIN: Okay. We will ask people to take one more look at it. We will just go over the questions briefly tomorrow in our breakout session. And I think we are done. See everyone tomorrow at 9:00.
[Whereupon, at 5:17 p.m., the meeting was concluded.]