[This Transcript is Unedited]
Hubert H. Humphrey Building
200 Independence Avenue, S.W.
Washington, DC 20001
Proceedings by:
CASET Associates, Ltd.
10201 Lee Highway, Suite 180
Fairfax, Virginia 22030
(703) 352-0091
TABLE OF CONTENTS
Agenda Item: Welcome and Introductions
DR. COHN: Would everyone please be seated, we'll get started.
Good morning. I want to call this meeting to order. This is the first day of two days of meetings of the National Committee on Vital and Health Statistics. The National Committee is the public advisory committee to the U.S. Department of Health and Human Services on national health information policy.
I am Simon Cohn. I am the Associate Executive Director for Kaiser Permanente, and Chair of the committee. I want to welcome committee members, staff and others here in person. I do want to send a special welcome to those listening in on the Internet. I want to remind everyone as always to speak clearly and into the microphone so those listening in on the Internet can hear us.
With that, let's have introductions around the table and then around the room. For those on the National Committee, I would ask if you have any conflicts of interest related to any issues coming before us today, would you so publicly indicate during your introduction. I want to begin by observing that I have no conflicts of interest. Marjorie?
MS. GREENBERG: Good morning. I am Marjorie Greenberg from the National Center for Health Statistics of CDC, and Executive Secretary to the committee.
MR. HUNGATE: Bob Hungate, Physician Patient Partnerships for Health, member of the committee, no conflicts.
DR. WARREN: Judy Warren, University of School of Nursing, member of the committee, no conflicts.
MR. REYNOLDS: Harry Reynolds, Blue Cross Blue Shield of North Carolina, member of the committee and no conflicts.
DR. VIGILANTE: Kevin Vigilante, Booz Allen Hamilton, member of the committee, no conflicts.
DR. HOUSTON: John Houston, University of Pittsburgh Medical Center, member of the committee and no conflicts.
DR. ROTHSTEIN: Mark Rothstein, University of Louisville School of Medicine, member of the committee, no conflicts.
PARTICIPANT: Member of the committee, no conflicts.
MR. LOCALIO: Russell Localio, University of Pennsylvania School of Medicine, member of the committee, no conflicts.
MS. TRUDEL: Karen Trudel, Centers for Medicare and Medicaid Services, liaison to the committee.
MS. MC ANDREW: Lynn McAndrew, Office for Civil Rights, privacy liaison to the committee.
DR. STEUERLE: Gene Steuerle from the Urban Institute, member of the committee, no conflicts.
DR. W. SCANLON: Bill Scanlon from Health Policy R&D, member of the committee, no conflicts.
DR. CARR: Justice Carr, Beth Israel Deaconess Medical Center, member of the committee and no conflicts.
DR. FITZMAURICE: Michael Fitzmaurice, Agency for Health Care Research and Quality.
MR. BLAIR: Jeff Blair, member of the committee, no conflicts.
DR. STEINWACHS: Don Steinwachs, Johns Hopkins University School of Public Health, member of the committee, no conflicts.
MR. J. SCANLON: Jim Scanlon, HHS, Office of Planning and Evaluation, Executive Staff Director for the full committee.
DR. COHN: I want to welcome everyone to our fall meeting. I hope everyone has had a good summer.
Before we move into the agenda review, I want to begin by thanking you all for your commitment, dedication and hard work over what has been a very busy summer. Certainly this summer has been a productive time for the committee. Since our last full committee meeting, we have had a strategic planning retreat, and we will be discussing some of the process improvement recommendations later on in our session.
For that meeting I do want to thank Carol McCall, who is not here today, as well as Marjorie Greenberg and Debbie Jackson for their help and leadership in terms of putting this together. I personally thought that the retreat was very thoughtful and productive. I want to thank you all for your participation.
The information as you know from the retreat was further discussed by the Executive Subcommittee at their July meeting. I think refinements are identified under Tab 3, which we will have some time to discuss both today and tomorrow.
The work of the Privacy Subcommittee continues unabated. That word is used advisedly. They produced an excellent report on privacy and the NHIN. That had extensive discussion at our last full committee meeting.
More importantly at least from my perspective, I am seeing the letter becoming an increasingly important document in the health care community, being referenced as well as being used as a primer when others are seeking to explain the issues relating to privacy and the upcoming NHIN. So I want to thank the subcommittee for their hard work. Of course, they haven't stopped there. I know they have been having conference calls over the summer. To my understanding, the next set of hearings for the subcommittee begin on Thursday at around 2 o'clock, and will continue on through noon on Friday.
Population has also had a number of conference calls over the summer, and has hearings scheduled for this fall on data linkages, and I know is planning hearings on surge capacity.
The Quality Work Group has been active, and is forging a strong ongoing relationship with AHRQ on a variety of both shorter term and longer term issues. The Subcommittee on Standards and Security held a hearing over the summer on issues related to the national provider ID, and will be holding additional hearings this fall on implementation issues. They also considered issues relating to a CHI recommendation on the allergy domain, which will be coming before us as an action item later on today.
Finally, I want to give special thanks to the ad hoc work group on the NHIN. I have been chairing that this summer. It has been a lot of work for everyone involved. Since our last full meeting, we have had a meeting and participated and helped sponsor the first Office of the National Coordinator forum, which was on that topic. That was followed by a hearing of the NCVHS. In July we had another two days of hearings, have had open calls. Even though Mary Jo isn't here, I would observe -- and we will talk about the document later on today -- that the document that we will be discussing was a result of many people working over Labor Day weekend to finalize for your review.
I do want to help set expectations. It is listed in the agenda as an action item today. As a result of conversations and agreements between the NCVHS and the Office of the National Coordinator, we have decided to extend the deadline for the completion of that report by one month, in other words, to the end of October, to allow for fuller public input, which will be in the form of open calls and other methods, as well as presentation and discussion at the Office of the National Coordinator's next forum, which will be in the middle of October. We believe that this is an important foundation document, and we want to make sure we have as much public input as possible to make sure this is validated and that we haven't missed anything.
Having said that, it is important that we discuss it today. The intent will be that in late October there will be an open conference call with the full committee to have final consideration of that document. So we want to make sure that everybody is as familiar and comfortable with at least the base set of observations and recommendations today, so that that call will go easily. As I said, that will continue to be a major issue for the meeting today.
Of course, all of this -- as I said, take a deep breath, there has been a lot going on this summer.
MS. GREENBERG: No down time.
DR. COHN: No down time. I think we used to think of summer as -- I don't think there has been much of a summer for many people in terms of off time. This is of course against a background of intensified Congressional and Department activity. Jim will be talking about the House and Senate HIT legislation. As you know, there has been legislation passed in both the House and the Senate, and will go to conference committee. What happens to that is uncertain at this point, based on the conference committee decisions as well as any sort of administrative action related to actually signing whatever may come out from that.
There has also been a President's Executive Order which you have in front of you on transparency. It has a much longer name which I will let Jim go into.
Within HHS, Secretary Leavitt continues to consider promotion of interoperable HIT to be a key priority. His leadership on this issue has been phenomenal. On all of this we are continuing to advise him and helping him stay a step ahead of many of the other activities going within HHS on these issues, so we can provide timely and useful advice. And we also have liaisons such as John Paul Houston, Mark Rothstein on various AHIC work groups also providing input and helping provide direction and insight.
In sum, lots happening, not a quiet time. I don't think anyone should be expecting it to get any better as we move into the fall.
With that, let's move into the agenda review. This morning we begin with an update, Jim Scanlon, Karen Trudel from CMS, Sue McAndrew from the Office for Civil Rights on what is happening with the Department and the issues coming before them.
After that, we are going to spend a couple of minutes talking about the full committee retreat and recommendations on process improvements. What I will tell you is that we are going to maybe be moving things around a little bit, depending on how our time frame goes. We have John Loonsk coming in to give an update from the Office of the National Coordinator at about 11, and then we are going to be moving into discussions of the NHIN report at that point. So we may just begin to get into the issues relating to process improvement. We may divide it up. We may talk a little bit about it then, we may talk about it in the middle of the afternoon. We will certainly have time tomorrow to be talking about that. So we will find time to discuss things and make sure that everyone is in agreement with how the Executive Subcommittee has distilled the thoughts of the full committee from their June retreat.
The NHIN discussion will occur. This is not an action item, but we want to make sure everyone is comfortable. By mid-afternoon we will also be bringing forward a letter from the Subcommittee on Standards and Security on the CHI allergy recommendations. I think we will have a copy in our hands by late morning or early afternoon on that.
At 3 o'clock, we have a presentation by John Halamka, who is chair of HITSP. HITSP as you know is one of the contractors from ONCHIT, and is doing tremendous work in terms of moving towards interoperability standards in health care.
At about 4 o'clock, we will adjourn the full committee and move into breakout sessions for the NHIN work group, as well as the Population Subcommittee. Those will last until around six o'clock.
This evening, I want to thank Marjorie Greenberg for being a gracious hostess as well as our Executive Secretary in hosting the committee to what is going to be an informal evening and barbecue, underlying informal if you can tolerate it. Suits will be accepted, but if you wanted to dress down I think that will be appropriate, since it will be at her house.
Before we move into the review, very briefly, tomorrow morning the Quality Work Group starts at eight o'clock in the morning, and I don't think that is going to change. The full committee starts around nine. A little bit after 11 we adjourn the full committee and start a joint session with the Board of Scientific Counselors, which will continue over a working lunch, and we will adjourn promptly at 1:45. This has been a meeting that has been in the planning for some time now, and that should be a very interesting exploration of commonalities of interest and possible synergies. We will talk more about that tomorrow.
Any questions?
MR. REYNOLDS: Simon, one thing we didn't mention, there was another letter coming forward from our committee, Standards and Security, which was matching patients to their health records. As we were working on the NHIN letter, we realized that that is a significant age requirement for that, so we moved the findings and recommendations from that letter, rather than bringing it in as a stand-alone situation. We just incorporated it as one of the findings and recommendations, and I will address that as we go through the letter later.
So that letter will be incorporated in there. So all the work and all the testimony we heard will be incorporated into that as a finding, rather than just send it forward as a stand-alone functionality that has got to be a key part of the NHIN anyhow. So that is the way we have decided to push it.
DR. COHN: Harry, thank you for your comment and clarification.
So with that, why don't we lead off? Jim, do you want to start with the updates?
Agenda Item: Update from the Department
MR. J. SCANLON: Thank you, Simon, and good morning, everyone. Since we met in June, as Simon indicated it was actually a very busy summer, a number of developments in health information policy heard over the summer and continue to occur.
I wanted to talk about two specifically this morning. Let me start with the President's Executive Order issued on August 22. You have a copy of this before you, and you probably know at least the general outlines of it. It is called an executive order, so it applies to federal agencies. It is entitled Promoting Quality and Efficient Health Care in Federal Government Administered or Sponsored Health Care Programs.
The purpose of the order is to insure that health care programs that are administered or sponsored by the federal government -- so this could be the DoD health care system, the Veterans Administration health care system and the programs that HHS finances more indirectly such as Medicare, Medicaid and so on -- at any rate, that these programs promote quality and efficient delivery of health care through the use of health information technology, transparency regarding health care quality and price, and better incentives for program beneficiaries, enrollees and providers.
The directive to the agencies is on page two. So you will see how this would work, under health information technology each agency would be directed as it implements, acquires or upgrades its health information technology systems used for the direct exchange of health information between the agency and non-federal entities, it shall utilize where available health information technology systems and products that meet recognized interoperability standards. Those are the standards that are under development through the AHIC process, through the HITSP process and through the CCHIT process, and that the Secretary would recognize.
So not only in the direct federal health care programs, but now in contracts with federal agencies, each agency shall require in contracts or agreements with health care providers, health plans or health insurers, that as each provider, plan or issuer implements, acquires or upgrades health information technology systems, it shall utilize where available health information technology systems and products that meet recognized interoperability standards. So again, the focus here is on a convergence, on standards, on certified systems and so on.
In addition to the health information technology provisions, there are provisions in the executive order that relate to quality measurements, transparency of quality measurements. Each agency is directed to implement programs measuring the quality of services supplied by health care providers to the beneficiaries or enrollees of a federal health care program. Such a program shall be based upon standards established by multi-stakeholder entities identified by the Secretary or by other agencies subject to this order.
In addition to pricing information, each agency shall make available or provide for the availability to the beneficiaries or enrollees of a federal health care program the prices that it and its health insurers or its health insurance plans pay for procedures to providers in the health care program with the agency and others as well.
So you can see, the Secretary is tying together the health IT initiatives, the transparency, health care quality and price and cost initiatives in one executive order and using the purchasing power of the federal government in these cases.
The implementation. The agencies are directed to comply with the requirements of this order by January 1, 2007. But as you see, it would affect contracts and systems upgrades and so on that would occur after that point.
As usual, we have the usual caveat. The actions directed by this order shall be carried out subject to the availability of appropriations and to the maximum extent permitted by law. Again, nothing in this order is meant to increase federal expenditures.
So that is the executive order. I will go into the health IT bills in a minute. Do you want to take any questions?
MR. HOUSTON: Being an attorney, I always look at the specific words. I think it is interesting that they use the phrase, recognized opportunity standards. My question is, what does that really mean? Definitionally, what is a recognized interoperability standard? Is there something that gives guidance as to how that is defined?
MR. J. SCANLON: That is yet to come. I should say that our interagency and interdepartmental health IT policy council will be looking at specifically how to implement this. I think it is envisioned as one possibility that there would be some process of recognition. The Secretary of HHS would recognize certain activities or standards, like HITSP standards, for example.
MR. HOUSTON: So a vendor couldn't simply decide that a recognized standard is anything they recognize?
MR. J. SCANLON: No, it is recognized by the Secretary of HHS. So there will be somewhat of a formal process of recognition.
MS. GREENBERG: It says it under D, page two.
MR. HOUSTON: I see it now.
MS. GREENBERG: Could this be seen as an extension of the work that was done under the consolidated health informatics with now the broadening with the HITSP and the CCHIT?
MR. J. SCANLON: It certainly might. This is now the next step in that process, the CHI process. Our commitment in other agencies, we agreed that we would use that first set of 23 -- two sets of 23 clinical data standards that we would use. This is the next step.
It is our hope that the CHI standards are incorporated into overall standards that HITSP would be developing as well. We certainly have been pressing for that.
DR. W. SCANLON: This may be for Karen. The question I have is, how does this impact the Medicare conditions of participation? Will they be modified to reflect the provision for contracting purposes that all providers would be covered by this?
MS. TRUDEL: I think that is another thing that we are still trying to go through, what do we mean by a contract.
DR. W. SCANLON: Or agreement.
MS. TRUDEL: Or agreement, exactly. Some are pretty clear-cut. We have contracts with our Part D plans, their Medicare Advantage plans, but some of the other issues are not as clear. The HIT policy council will be walking through some of those issues, because other agencies have similar concerns.
MR. BLAIR: Are we likely to see this executive order and the requirements for this extended as well to any federal grants for various types of RIOs or health information networks?
MR. J. SCANLON: That is a good question, Jeff. I don't think the executive order actually talks to that directly. We have always in the health IT policy council thought about three rings of the federal health programs, those that are directly administered like the VA and the DoD and the Indian Health Service. The second ring are those that we support or finance or sponsor through contracts or other means. Then the third is the other instruments that agencies use, agreements and grants and so on, but they are not direct health care programs, demonstration programs or research programs.
I think the focus here is probably on the first ring directly with the highest priority, then the second ring, and it would probably -- rather than to try to do everything at once, I think it is trying to do a few things well. So it would be the direct health care programs and how it might relate to contracts, and then later what grant programs for example would be affected.
So obviously it would make sense as an informal policy at any rate that where applicable, where relevant, the standards would be used, at least as the first look.
DR. COHN: Just to further clarify, I think the NHIN functional requirements may get more to that point. Anything that is going on now, where federal support of RIOs comes as a grant out of AHRQ.
Mark Rothstein, and then we will let him move on to his next issue.
DR. ROTHSTEIN: Jim, I just had a brief question about the relationship between the interoperability standards that are going to be developed by the Department to implement this executive order and the interoperability standards that are being developed for the NHIN.
Many times in various contexts, what the federal government does by executive order or otherwise sets the stage for what the private sector is expected to do. So my question is, are these standards going to be developed in tandem with the NHIN? Because there would be a problem, I would think, if they were developed first and then the NHIN would have their own standards later on, because the train would have left the station.
MR. J. SCANLON: I think the desire in the plan is to have all of these -- I think we are focusing on the HITSP standards first, and then as a network type, NHIN standards move forward as well and have some formal recognition as well, that they would come in as well.
I think it is a bit nebulous. This is a 30,000-foot level, and the devil is in the details. What standards exactly would be recognized would be a crucial point.
DR. ROTHSTEIN: Thank you.
DR. COHN: Jim, I am going to let you move on.
MR. J. SCANLON: Let me talk about -- and I think many of you have been following the developments on the Hill. I understand there were something like 50 health IT bills introduced at various times. There are now two that seem to be the focus of attention, one in the Senate and one in the House, and they are quite different in their provisions. Technically it is not a conference that they go to, technically it is a pre-conference.
But there are some provisions that relate directly to the NCVHS committee and issues that the committee has been working on. They are particularly in the House bill. The Senate bill as I remember doesn't contain these same provisions. So these will have to be worked out. NCVHS is providing technical assistance to the House and the Senate staff on this.
I might point out, there are not a lot of legislative days left in this Congress, so it will be a challenge to pull all this together. But at any rate there is a lot of activity to see where the common ground is.
But first of all, let me focus a little bit on the House bill. The House bill has a number of provisions that would direct the Department to adopt several standards. One would be -- and a time line which is proposed as well, which I assume is subject to discussion, but in terms of upgrading the X12 standards, the House bill would direct HHS to promulgate a final rule that would adopt the X12 version 5010 standards by April 1, 2009. Prior to that, it would direct HHS to issue a final rule adopting whatever is the current version of the NCPDP standards two years earlier, April 1, 2007. Then in 2010 it would direct the Department to adopt and promulgate a final rule that would adopt ICD-10 for transactions and services occurring after October 1, 2010. So that is the time line and that suite of standards that is outlined in the House bill. Again, these will have to be worked out between the Senate and the House staff.
In addition, the House bill includes a process for streamlining and updating the HIPAA transaction standards. I think our folks believe it applies not to the privacy or the code set standards, but to the transaction standards.
Let me give you the overall view, because the pathway is a little complex. The overall view would be, as you know currently the various standards development organizations do their work through their open process, through the accredited ANSE process. They would work on modifications and additions to the standards. They would then put the standards through a balloting process and so on, a public comment process, and then they would finalize. Then those standards at that point, once they had been adopted by the accredited organization, then the HIPAA process begins. Then the HHS has a role in recommending standards. Then a proposed rule is developed, and then notice and comment is taken on that rule, and then a final rule is developed. So it is a lengthy process.
The concept here is to use the SDO public accredited process for that first stage of the proposed public comment and rule that would occur with the proposed rule. So if you think of the sequence, an SDO would notify the Secretary -- if it passes in this way, would notify the Secretary when it was embarking on modifications or additions to an existing standard. The Secretary would publish a notice that this process was beginning and particularly what the content was, what the process was for public participation. So it would use the SDO public process in place of the proposed rule public notice and comment process.
At a later point when there was a draft of the standards, for example, the SDO would again notify the Secretary. The Secretary would issue a notice in the Federal Register that this was available for comment, how you would get a copy of the draft and so on, how you would participate and so on.
The SDO would be expected to carry out its process in the consensus process. It would be expected to address the comments, not necessarily do what the commenter said, but address the comments just as we have to do with comments on proposed rules, and then develop a final set of standards.
The NCVHS, when the SDO has reached that point where there is a standard that has completed that process, the SDO notifies the Department. The NCVHS then would be required to have a public meeting and take comment on that standard, and then make a recommendation to HHS to adopt or not adopt.
Again, it would require public notice. I think as I look at the time line now, it would be 120 days from the time that the SDO notified the Department that it had a final standard that the committee would be asked to set up the meeting and make its recommendation. I think originally it was 90, and we said that was an awfully tight time line for a public advisory committee.
Then the Secretary would either adopt or not adopt, and he would describe in a Federal Register notice what the decision was and what the reason was. So it would really give the NCVHS yet another role not unlike the DSMO role, but it is much more serving a sensitive role in the notice and public comment part of this. I think in many ways that is a recognition that the NCVHS process is a transparent and an open and a balanced public process.
So we will have to see what eventuates between the House and the Senate if this should pass this year
There are a couple of other things in both bills. The Senate bill has a number of funding grant programs and so on. I think the House bill in its current version has a couple of those as well. There are provisions relating to privacy, mostly looking at studying privacy. There are, study and report to determine the impact and variation and commonality in state health information laws and regulations. There are safe harbors to our anti-kickback civil penalties and criminal penalties, as well as exceptions to the anti-referral, physician referral positions as well.
As you know, HHS has already issued final rules on these issues, so we have to see how that all would coordinate if these bills become law. There would be a requirement for a strategic plan or health information technology indicating how the AHIC and all of the other pieces come together. Both bills as I recall would codify the Office of the National Coordinator for health information technology. There are some provisions related to the health information community as well, some sort of a report.
I have given you just the outline of what is here. I don't want to go into details. We don't know how exactly this would work out between the two or what the time line would be. But clearly the NCVHS would have a central role in the upgrading and the addition and modification process, and some of the standards that the committee has recommended would be promulgated as a final rule.
Let me stop there and take any questions.
MR. REYNOLDS: Jim, thanks. I know all of this is awfully hypothetical until it passes, but if NCVHS does take the role that you talked about on transactions, would it also be envisioned that our role would be to recommend the implementation date to the Secretary? There is a difference between agreeing to a standard and then agreeing to when -- or at least recommending when the implementation should occur.
MR. J. SCANLON: I think that would be part of the committee's recommendation.
MR. REYNOLDS: Thank you.
DR. COHN: Jim, is this the end of your presentation or do you have more?
MR. J. SCANLON: Yes.
DR. COHN: I'll allow Jeff one question, Russ one question, and then we'll move to the other presenters.
MR. BLAIR: As many of the standards begin to develop new versions, the amount of review might be fairly substantial. Do you know if there is any thought to providing resources to the NCVHS to handle the increased volume of reviews that may result?
MR. J. SCANLON: I can answer that. There is nothing in the bills. I think Congress thinks they already appropriate for HHS. But I think we would have to go to HHS. We would have to look at what the requirements are. If this passes we will do it. I think this basic streamlining process is something we have all been looking for, anyway.
Yes, there is still a public protection and public comment provision here, so we would have to look internally at what additional resources were needed.
MR. LOCALIO: Just for our benefit and those in the room, do you have the Senate and House bill numbers?
MR. J. SCANLON: Yes, I do. The House bill number is H.R. 4157 and the Senate is S.1418.
DR. COHN: Jim, thank you. It is a useful outline.
MR. J. SCANLON: A lot of things underway.
DR. COHN: A lot of things in play. Karen Trudel, I think you are up next. Thank you for joining us.
Agenda Item: Health Insurance Portability and Accountability Act
MS. TRUDEL: Thank you. I am just going to cover a few updates that have to do with HIPAA and e-prescribing.
I will start with a new news items for HIPAA transactions. The Medicare contingency for the electronic remittance advice, which is the transaction that the plan sends to the provider explaining what they did with the claim, any adjustments, payment amounts, et cetera, will end on October 1. We have been sending over 99 percent of compliance PRAs since July, and it was time to cut that off. So as of October 1, all of the electronic remittance advices that we send to providers will be HIPAA compliant.
Eligibility and query responses from providers to Medicare asking information about Medicare eligibility. We have been doing these transactions via a closed network for well over a year. We are processing approximately two million of them per week. That volume has pretty much leveled off at this point.
We have an Internet pilot that has been going with about 20 users to do eligibility queries and responses through the Internet, which is a very new thing for CMS. As I said, we have about 20 users now. We are expecting to add several thousand over the next few months.
This Internet based transaction is what we expect individual practices to use. The closed network version of this is primarily done through clearinghouses. So we will have two different mechanisms for doing electronic eligibility queries and responses which saves us a lot of time and saves providers an awful lot of time on the phone.
I'll talk a bit about the national provider I.D. Simon mentioned that there have been discussions with the Subcommittee on Standards and Security on implementation issues. Just to update, the compliance date is May 2007 for including NPIs on HIPAA transactions. Small plans have an additional year until May 2008.
The NCO system, the enumerator has enumerated approximately 1.2 million providers to date. Their monthly volume of transaction is about 200,000, and when they do the math they feel pretty comfortable that we will be able to get everyone enumerated in time.
The data dissemination notice, which is our description of how we will provide data from the NCO system to a variety of different users, still is not published. The document is still in review. This is something that plans have indicated is extremely important to them in terms of their implementation. We are moving as quickly as we can to get it on the street and begin the data dissemination process.
Obviously, because the document is still in review I can't address specifics, but our proposal would provide for a variety of different data sets and data access methods to accommodate a variety of needs, from a large plan's need to build a crosswalk for all of its providers at one time, to an individual physician's office looking for another provider's NPI because they were referred to them and they need to put that on the claim.
We met with the WIDI group recently to discuss concerns about the potential for difficulties and lapses in claims processing just after the May 2000 deadline. A number of plans are concerned that if providers wait until the last minute to get their NPI, and they want until the last minute to use their NPI, which is perfectly compliant behavior on their part, the plans won't have enough time to add those new NPIs to their crosswalks by the compliance data, and the result of course is that those claims would be rejected. Obviously, no one wants that. We are going to be working with WIDI and other plans to develop some outreach messages for providers so that we can encourage them to obtain and begin to use their NPIs on HIPAA transactions well before the compliance date to insure that there won't be any lapse in claims processing, and that that will provide for an adequate testing and ramp-up period for providers and plans. So we are going to be pushing that message in the coming months.
I don't know whether I reported before that there was a joint two-day HHS and DEA hearing about e-prescribing for controlled substances. DEA's initial position was that a PKI solution would be necessary in order to assure them enough non-repudiation to engage in legal proceedings having to do with criminal cases of drug diversion.
We heard testimony from a number of industry experts, software developers and organizations that are involved in controlled substances monitoring. One of the messages that we heard was that a PKI solution on a broad scale would be so burdensome to providers that it would definitely have a chilling effect on use of e-prescribing. Also, a solution that would work across the board for e-prescribing of controlled substances and non-controlled substances would conversely have an accelerating effect on e-prescribing uptake, because you could use the same processes and products for those controlled and non-controlled substances.
The testimony highlighted the features of the e-prescribing products that are already out there. There is authentication throughout the prescribing process, beginning with the physician's office, and moving through the network and to the pharmacy that don't exist today in the paper process. There are audit trails inherent in e-prescribing software that don't exist today. These additional features could actually mitigate risk and provide some additional needed evidence.
DEA is reviewing the testimony. HHS will be working with them to assure that we can find a plan to move forward that works for everyone. We will be talking about that in some more detail in the October Standards and Security hearing.
Let me finish with the e-prescribing pilot. Just to remind you, we are nearing completion. The end is December 31. We are doing site visits, and all the pilots are yielding extremely valuable information.
The first priority for the pilot is to test the standards, do they transmit the appropriate data unequivocally, understandably, in a manner that is useful by the receiver. Obviously that is step one, in order to move on to additional standards on top of the foundation.
The second priority is return on investment, how does e-prescribing impact how physicians write prescriptions and how they prescribe. The Minnesota pilot is also testing the use of e-prescribing in the long term care setting, which is different from the ambulatory setting because the physician and facility personnel are involved in the prescribing process.
Our evaluation contractor will be on board shortly. Our report to Congress is due in April of next year, which is a very tight time line, and we will also at the same time be moving forward on a proposed rule that will propose any standards that the pilots indicate are ripe for adoption at the time.
I'll take questions.
DR. COHN: Sure, why don't we take a couple of questions, and then we will get to the final presentation.
MR. BLAIR: Karen, thank you for the good news on the progress that has been made with respect to HHS and the Drug Enforcement Agency coming closer to an agreement on e-prescribing.
Could you tell us a little bit whether the fill status notification played a role in allowing the Drug Enforcement Agency to feel a little bit more comfortable that they know that if a prescription has been filled, that that also is a vehicle for non-repudiation?
MS. TRUDEL: I can't speak for DEA, but I do know that that was one point that was brought up consistently by the testifiers, that the fill status notification if adopted for controlled substances would definitely be a tool. A physician that did not prescribe a controlled substance receiving back a notice that the prescription was filled is obviously going to want to look into that. So it closes a loop where that solution didn't exist before.
MR. LOCALIO: Karen, you need not answer this question, you may not know the answer to it. But several years ago I raised an issue wherein Steve Steindel and I engaged in a conversation. It had to do with the fact that although e-prescribing is upon us, the FDA still doesn't have a database that has all the medications in it.
About a month ago, there was a report of somebody far more knowledgeable than I that confirmed that. I am wondering, is anybody doing anything about filling that gap, so that when we have e-prescribing, we have a standard that says somebody somewhere in the public sector has a database that actually has the drugs that are being prescribed? I know for a fact that the FDA database does not have drugs that are currently being prescribed. Or is this out of our purview, not a standard, not an issue?
DR. COHN: Russ, I'm sorry we don't have Randy Levin here from the FDA to help respond to that. But Karen, would you like to --
MS. TRUDEL: I can't speak to the completeness of the database at this point. One of the things that we are testing in the pilots is the ability to link up RX-Norm with the NDC to get the name of the drug the way the physician would prescribe it, as opposed to the drug the way it comes out of the bottle. So we are looking for that linkage.
MR. BLAIR: I have a little bit of the answer to Russ' comments. Steve forwarded your note with his comments to the Subcommittee on Standards and Security, and we are working to set up a series of testimonies to follow up on your very appropriate and valid question, and to get Randy Levin from the FDA as well as how that relates to folding in the NDC codes and mapping in the NDC codes to Rx-Norm.
So it will either be in the October SSS meeting or the December SSS meeting. Right now we are trying to see if we can fold it into October. So Russell, thank you for alerting us to this issue.
MR. LOCALIO: Jeff, thank you.
DR. FITZMAURICE: And I have a follow-up, too. That is, for the past three years AHRQ has funded FDA and National Library of Medicine to put drug information through FDA approval and onto a website at the National Library of Medicine. AHRQ has funded the development of RX-Norm, and we are funding at FDA a product listing database that will include not only drugs, but other things as well such as over-the-counter drugs, and we are funding a unique identification code set, that you can unique identify the active ingredients first of all in drugs, an d then we are going to move to the inactive ingredients. The intention is that that all will be publicly available.
MR. LOCALIO: Thank you again.
MR. REYNOLDS: Karen, I sense maybe a significantly different message on NPI than we probably heard in our last Subcommittee on Standards and Security, where WIDI was asking for as much as a six-months transition period. I think you basically stated that you feel that everybody will have their number and the outreach will take care of it.
Are you still going to look at that? We are covering this again in October in our hearings.
MS. TRUDEL: The WIDI concern was predicated on the basis of what if everyone waits until the last minute. I think what we came away with from our last meeting with them, which was I believe just last week, was what can we do to keep everyone from waiting until the last minute.
We think it is feasible that we can enumerate everyone in time, and we think it is feasible that people can start using the NPI in transactions. If we can get out messages that stress how important that is, we might not need to move to plan B, which would be in WIDI's proposal continuing to process dually for a period of time after the compliance date. I think that is preferable for everyone.
MR. REYNOLDS: So if that doesn't work and the requirement is everyone be ready, because WIDI talked about a six-month, would there be any kind of an enforcement or anything else on 2007 for people that weren't. If you could add that to your testimony as we come forward, because I think that will be an interesting tipping point question.
MS. TRUDEL: I just don't think that we are in a position to know that at this point. I think we need to keep an eye on how the enumeration is going, how many people are using the NPI, and wait a little while before we find out whether there is really a problem, and the scope and magnitude of the problem.
DR. COHN: I would jump in on this one. I am reminded of the 837 implementation from several years ago. It is really the responsibility of the NCVHS to monitor the situation and make appropriate recommendations as needed. We may be a little bit early.
I think the appropriate response right now is monitoring and keeping close tabs on it, as opposed to coming up with a solution at this point.
Other questions for Karen?
Agenda Item: Privacy Rule Compliance Update
MS. MC ANDREW: It has been a busy summer for us all. Keeping up with all of the events, not only with your committee, but with the AHIC, has really kept my staff hopping.
We are participants in two of the AHIC work groups, the consumer empowerment one, which is focused on the personal health records, is one of the committees that we are monitoring. They have been aggressively looking into existing models of personal health records. We have been doing these WEBAC shows, and they have been fascinating.
So my hope that the personal health record can be a contributor in this electronic world has been reinvigorated. I had dim hopes there for awhile, but it is looking much brighter.
Also, the AHIC has launched finally the privacy and confidentiality work group. It had its first meeting last month, July, August. They also are marching their way to their first public hearing at the end of this month, and there will be other committee meetings in the interim. So that committee is running to catch up because there was some delay in its formation. So I am expecting that they will have a very heavy and busy agenda for the fall and probably through the end of the year.
On the compliance front, we have received over 22,000 complaints as of the end of August. We continue to maintain a closure rate of 75 percent. We are looking into ways of extracting from our database more information about those closures. I think we are pretty close to having a report that we can track over time the nature of those closures and have a more full report for the committee at future meetings.
I was hoping to debut it at this meeting, but it wasn't quite ready for prime time. One more scrub, they wanted. But I am hopeful that we can launch off of that report into drilling down even more deeply into the data that we now have on about three years of complaint activity to find out more about what is going on on a broad policy scale.
In addition, we have initiated an effort to try to focus some of our -- give priority in our investigations to those cases that are coming in that involve complaints about an individual right violation, that someone is denied access, or that someone has not had an amendment made to their record or other kinds of problems that involve a complaint of individual rights under the privacy rule. We believe that these cases can have -- they are more resolvable than some of the other types of complaints. They are easier to investigate, and the complainant really needs relief on a faster track.
So we are trying to as part of our triage identify these cases and put them on a priority investigation track to accelerate the resolution of these types of cases. We hope to debut that system beginning in October.
On other compliance related fronts, we have been participating in the White House committee that is looking into addressing identity theft, and have been participating with them both in terms of work groups focusing on criminal laws with respect to identity theft as well as public education and outreach for consumers and data holders with regard to protecting against identity theft, and helping the consumer who may be the victim of identity theft.
So this is slightly off of our HIPAA track, but nevertheless is a privacy and confidentiality issue, and it does come up from time to time with regard to complaints that we have, and may also be a HIPAA violation when these kinds of incidents occur.
Along that line, the Department itself is taking a stronger and more organized approach to incidents of identity theft. We are participating in a subcommittee of the risk management committee that will be looking into data breaches and what the appropriate response of the Department should be with regard to those kinds of data breaches.
Finally, we have been working over the summer on a couple of issues that have arisen with respect to methamphetamine log. When you go to the pharmacy these days and want to buy your Sudafedamine, you have to sign -- hopefully they make you sign in the log. There have been some privacy issues that have come up with respect to the information that is in those logs, as well as access by the law enforcement authorities to the log.
We have been dealing over the summer with those issues with respect to state laws that control those substances, but as of October 1 there is a new federal law that is going into effect that will also mandate these logs be kept, and that federal law also has its own set of privacy protections for the information in the log. So we have been working with the Department of Justice on their regulations with regard to the protections for the information in these meth logs.
On other fronts, we have been busy with our emergency responder communities and working with disaster response teams to promote the understanding of how the privacy rule allows access to both disaster response planners as well as first response planners in the event of a disaster, to information that they need to carry out their functions.
We have in the end of June posted on our website a new tool that is specifically directed to disaster response planners to try to walk them through the privacy rule and how that rule affects their ability to obtain information and what they need to tell the covered entity about their source of information, what they are about, so that they can get access under the appropriate authorities.
We have had some very good feedback in response to that tool. It is a new approach, it is not the straight frequently asked question. It is an interactive tool where you can go in and push a button and a question will pop up, and you can follow the trail down to hopefully the right answer.
I think in the first six weeks or so, we had some 15,000 hits on that tool, so we are hoping that it is useful to the community. We are continuing to work with the various parts of the Department that are involved in disaster response, and in particularly with the Office on Disabilities to try to continue to focus our efforts and the Department's efforts in finding meaningful ways of meeting the needs of the disabled in these kinds of situations.
Finally, we have been doing a lot of work over the summer with our research community. We have formed a group within the Department of all of the staff that are involved in research to come together to talk about what the issues are with the research community with respect to the privacy rule and what is the best solution to those problems as a guidance; is it clarification on the research side, is there a need to modify the privacy regulation to accommodate some of the problems that the research community is facing.
We have also had some conversations -- there was a public hearing over the summer by the Institute of Medicine, who are also interested in doing some work in the area of how the privacy rule may be affecting research efforts. We are trying to work both within the Department and with the broader research community in order to try to come to a common understanding about what the problem really is.
Right now there is a lot of confusion and misinformation or disinformation about what the root cause is of some of the delay and upset that is being experienced within that community. Some of it clearly is just adjusting to a new set of requirements, change is always difficult, but after you get over that, there may be some fundamental problems that we are able to identify and address. So we are trying to work those out, and we had some very fruitful conversations over the summer which are now coming to a conclusion. I think one of the conclusions is to continue those conversations to focus on a couple of areas, including recruitment issues and some continuing issues with the level of identifiable information that is available for research efforts, particularly epidemiology type research efforts, they seem to be having the most problems with the current sets of rules.
So that is what has been keeping us busy.
DR. COHN: I'm glad we are not alone about working this summer. It seems like there has been a lot going on, and it is good to hear some of the work that you are describing.
John Paul, I think you had something?
MR. HOUSTON: I have a number of questions. I hope you don't mind.
First of all, I'm glad that you are developing the database, and I am looking forward to seeing what is in that, so hopefully next meeting. But I do have a number of questions and a couple of comments.
You discussed looking at prioritizing cases of individual access or changes requested to a record. The question I have is, are you trying to mediate those, or just simply reviewing that an appropriate process was put in place in order to -- the reason why I ask is, periodically at my institution we get requests to have a record changed, and there is a review process that goes on. Often the patient is not satisfied, because the physicians feel very strongly that the record is accurate.
Now, is OCR's level of review just to insure that there has been an appropriate review by the institution as to the patient's request for modification, or do they try to mediate and review whether there should be a change made?
MS. MC ANDREW: No, we would not be second guessing whether or not there would be a change made. It would simply be whether or not the process of amendment was done in accordance with the procedures required in the rule.
MR. HOUSTON: A couple of other points. Regarding the identity theft work you are doing with the White House, one of the things I implore you is that part of the reason why identity theft is such an issue is because the banking industry has decided that they want to be able to dole out credit very easily, and so therefore made a lot of decisions about how to dole out credit and how they were going to rely upon such things as social security numbers and things like that.
The reason why I bring that up is, I hope there is some reason put into the process they are going through at the White House, making sure that by responding to this identity theft crisis, you are not tying the hands of institutions that still in large measure, even if they have their own patient identifiers, rely in large measure on social security numbers to insure that we get the appropriate patient information.
A lot of hospitals, even if they are changing their medical record number, still have a lot of historical information that is based upon a social security number or identifying social security number. So I don't want to find that providers are disadvantaged because of an issue that I think in large measure came out because of financial institutions.
That is my second point. My third point relates to disaster response. I did quickly go through the guidance that you put out. As I recollect, the rule wasn't any guidance. Maybe I am wrong because I looked at it a number of weeks ago, but there wasn't a lot of guidance related to how institutions would be able to provide information regarding trying to locate individuals in the event of a disaster. Am I wrong in that?
MS. MC ANDREW: The guidance that we put out was largely focused on the disaster planning as opposed to the -- I think it was touched on, but we didn't design the tool to address all the means of releasing information during a disaster.
Now, we did do some of that. I think the tool links to some of the reminders that we did put out right after Katrina. We are looking for ways of expanding that tool.
MR. HOUSTON: Hospitals obviously need to get data about patients that are in their facilities, but I think there is also compelling desire to be able to provide information to local authorities and otherwise, that people that are lost can be found or located.
So to the extent that the guidance can be more comprehensive, I think it would be helpful to providers, especially if you are trying to provide them a one-stop shopping experience, as to how to deal with disaster situations. That might be helpful.
MS. MC ANDREW: I appreciate that.
DR. FITZMAURICE: Sue, two things. First, I want to compliment you on that tool. The tool is really good. It lays it out very clearly. I wish every government regulation, particularly the IRS, would follow the flow of the requirements and the questions to be addressed in meeting those requirements.
Secondly, there is no end of new issues to cover, and maybe even old issues. We deal a lot with RIOs and National Health Information Networks, and these components may exchange information between both covered and uncovered entities. Do you have any guidance that is specifically tailored to RIOs and state and local health information exchanges, things like record locator services, which says which providers have which records on which patients, access to clinical information beyond firewalls that authorize requesters can pull that information out at three o'clock in the morning if they are authorized? Do you have any guidance that says here is how the privacy rule applies to things like regional health exchanges and national health-wide information networks?
MS. MC ANDREW: Not currently. We don't have anything specifically addressing the privacy solutions in an NHIN environment. Some of that we have been awaiting more concrete results out of the privacy and confidentiality committees and work groups, as well as some more definitive models.
I think right now we are struggling with the infinite number of ways that this information can be arranged and what the interactions can be. It is just too indefinite to have meaningful guidance. So the rule applies to any of these exchanges as it would today. People do have electronic information systems, and they are bound by the rule, just as if that information is on paper.
We have been talking with ANC and we have continuing conversations with ANC about narrowing down the models and if we can get them down to maybe three or four models, whether we can then start doing more concrete mapping.
MR. LOCALIO: Susan, thank you for your update. I was most interested in your last set of comments about issues with the research community and the privacy rule.
You outlined very briefly for us the process by which you are going to move forward, the formal process by which you are going to move forward. You said you had some hearings with the Institute of Medicine over the summer, you are continuing the dialogue, but what is next? When do you get engaged in rulemaking? What is the timetable for that? When do you anticipate modification of the HIPAA rule would be proposed, noticed, comments? Are we talking about the next three months, six months, three years? How does that work?
MS. MC ANDREW: I think all of the above. No, clearly what is happening at the IOM is subject to their own time frames. I'm not entirely clear about how fast they intend to move. I think there were going to be some decisions made by the end of this year about whether the IOM would be mounting its own inquiry into this. If so, it would probably be an AP process before they would have reportable results.
I think the process that we are engaged in internally within the Department is right now primarily focusing on guidance that may be available. The time frames for that would be something that we would be working out as the issues get a little more concretely defined over the next two to three months.
If there is the need for regulation, it would certainly by something that we would put through notice and comment rulemaking. The time line for that however I would not speculate on at this point.
MR. LOCALIO: So we are talking about at least a couple of years if any rules would be coming up. You would wait for the Institute of Medicine to get through its --
MS. MC ANDREW: We would wait for the Institute of Medicine; it certainly would be that. There are some issues that come up that we can move forward on. It may be something that we would be looking to next year to do a rulemaking on.
DR. COHN: So what you are describing is, it may not just be one rule, but it may be a gradual evolution of the rule as you learn more?
MS. MC ANDREW: Yes. I think the rule itself -- the statute says you can only change a standard once a year. We are certainly not challenged on that right now.
DR. COHN: At this point, exactly. That is very well said. Jeff, I think you have a question?
MR. BLAIR: Yes. Susan, I wanted to thank you for the number of points you touched upon in your testimony. I found it very, very helpful to understand better all of the areas that the Office for Civil Rights is exploring beyond just HIPAA privacy complaints and resolutions. It was very, very helpful.
Michael touched on an issue which I have some interest in, since I happen to be affiliated with a health information exchange network. Given all of the things that you are working on, if anyone winds up coming up with others that they want to put on your plate, and if it turns out one of them happens to be health information exchange networks and the privacy issues related to matching patients to their records, which is an area I would love for you to do if you have a chance or if you are directed to do so, if that happens, I have two things that may help to maybe simplify or shorten or reduce the workload, if you are heading down that path.
One of them would be, I think a lot of the emerging health information exchange networks still have to go through legal reviews with every single provider and their attorney staffs be satisfied before they sign a data subscription agreement. That takes time. It is slowing down the process. They would love to be able to have some authoritative guidance from the federal government saying that the data subscription agreements meet federal guidelines for protecting privacy and security.
There is at least one effort that, if that ever falls on your plate, the EHI initiative has its common framework with guidance. If at any point you are asked to do that, and if that turns out to be something where you are able to look at that, that could maybe shortcut your efforts. If you are able to look at that and wind up letting all these RIOs and HIE networks, whether or not that is sufficient, that would be helpful.
The other piece is that all of the RIOs and health information exchange networks around the country now are developing data subscription agreements. I know that a lot of them would love to be able to find an entity that would wind up being able to say, yes, this meets federal requirements.
So those are the two comments that I would make.
MS. TRUDEL: Thank you, Jeff.
MR. BLAIR: Thank you again for your testimony.
MS. TRUDEL: I appreciate more work.
DR. COHN: I want to thank both of you for some very interesting discussions. I am hearing more action and activity coming out of the Office for Civil Rights than I think I can remember in a presentation that you have given. I guess the good news is that there is activity. Also the good news is that there seems to be some movement forward in terms of examining the rule, coming up with improvement tools that may help the consumer and others in the health care community understand the piece better.
I know that the Subcommittee on Privacy has made a variety of comments on research. It sounds like those pieces are beginning to move forward. So we will look forward to some continuing conversation, and I'm sure some of this will come out in the Privacy Subcommittee discussions and hearings as it moves forward also. So thank you.
Karen, it is heartening to me as we talk about broad brushes in the NHIN, I think many of us believe that e-prescribing is going to be a leading edge of NHIN, unless there is much more activity that occurs with RIOs than appears to be happening, at least in the next six months.
I keep hearing pilots and implementations of e-prescribing are just expanding at a great rate. So this may provide a really important foundation to all the work going forward. So my congratulations on that.
I should comment before we take a break that for November, we are going to be producing a year-end report on HIPAA. I just want to remind you all that this will be an action item for the committee in November. From my perspective, this takes on special significance, because we really are at the ten-year anniversary of HIPAA. There has already been a letter from the full committee on some lessons learned, but we are thinking about putting together a particularly thoughtful piece on where we have been over the last ten years and where we are now. So we would ask for both of your assistance as we begin to fashion such a document. We think that will come forward for action at our November meeting.
Now, with that, it is 10:35, we are already about five minutes late. Why don't we take about a 15-minute break, and we will come back at 10:50.
(Brief recess.)
DR. COHN: Why don't we call this meeting back to order. Between 11 and 12 and then continuing on to three, we are going to be dealing with a variety of work items. Let me just take a minute and review what we expect to be discussing.
We are expecting John Loonsk who is one of the directors of the Office of the National Coordinator to be arriving any moment. I know he is going to want to take a couple of minutes and just update us on the activities of the Office of the National Coordinator.
I should comment that we are anticipating going forward that will be putting ONC as one of the groups that updates the committee at the beginning of our meetings on a routine basis, since we have very close relations with them. But anyway, we will be asking John to provide us with a bit of an update.
Then from there we are going to be moving into discussions of the NHIN document that we prepared. You have all received that by e-mail. You have paper copies in front of you. I think those in the audience also have copies of the underlying draft document.
Just to reiterate that document, this is not an action item at this meeting, but what we want to do is to get your input and develop hopefully a level of comfort with the document, knowing that we are going to be seeking additional open public comment between now and mid-October, with the idea that we will finalize it during an open conference call the last couple of weeks of October. So this is an occasion to look through it.
As is a tradition with the committee, we do attempt to get everybody comfortable, have an opportunity to discuss and make sure everyone understands both the observations and the recommendations going forward, as well as the overall framing of the document. We are hoping that when it comes time to have final consideration of the document, it makes it a little bit easier and we aren't suddenly discovering that we have lots of modifications that need to be made to the document.
After that, and hopefully we will have time around 2:30 this afternoon to have a chance to move into our sole action item for the meeting, which is a letter coming from Standards and Security on CHI allergy. We will talk about it. If the letter seems like it is ready, we may choose to consider it and vote on it today, otherwise it will become an action item tomorrow.
As we fine time both today and tomorrow, we are going to try to talk about some of the process improvement pieces from Tab 3. What we may do is take small time pieces just to begin to go through them item by item.
I think what I am going to suggest is that maybe we take a minute just to review those items at this point. I know many of you have read them. This is Tab 3. What we are looking for is, this is work that you all did in the retreat in June as was abstracted by the Executive Subcommittee and further abstracted by Marjorie Greenberg into what we think is a document where it is a mixture of proposed process improvements as well as what our priorities are, so a reaffirmation of some of our priorities. We just want to make sure that everybody is consistent with that.
Now, I am jumping to the end, which has to do with exchange of information about members' expertise and interests. That was something suggested at our June meeting, and resulted in the action that we asked everybody for their half-page bios, which most of you have received. I of course was late for the deadline, which is why you have mine here, but I think it is an opportunity for everybody to understand who we all work with.
The other piece of that is that I think there was a suggestion that we have members from time to time either at dinners or during the meeting take opportunities to have additional comments about the work that they do outside of committee work. We may very well implement that. I think it almost may be more interesting as a dinnertime activity, but depending on what people are doing some of it may have relevance to the full committee. So that is one piece that we have already begun to implement, and hopefully everybody is okay with that.
Given that we are into this at this point, do we want to spend a couple of minutes talking about priorities? I don't know whether we will make it through the overall item, but at least we can begin to get into it, and then we will have additional conversations and move on.
There are a couple of bullets here. Let me just go through them briefly. We shall continue to take regular reports about departmental and industry priorities. That is probably unchanged from what we have been doing heretofore.
I think we are suggesting as a potential change in the process that outside speakers when we invite them to present, we are going to be a little more -- not directive, but we are going to ask a little more carefully and get objectives from them before they present, so that we can make sure that their topics really are useful for our conversation. We are going to make sure that everybody has time for questions and all that. I think we have seen that for example today even with our departmental review, I think there was the feeling that there was enough time for questions and discussions.
Agenda Item: Full Committee Retreat
I think we also -- I'll stop in just a second and defer to John Loonsk, since he has arrived -- is the issue about the value of full committee retreats. As you will remember, up until now there has been pretty much -- retreats have been reserved for Executive Subcommittee activities once a year.
I am curious about everybody's thoughts, but I thought that pulling the full committee together for retreats, and it doesn't necessarily need to be yearly, but from time to time, was a very useful and helpful exercise. I would just ask for all of your senses of whether it is something we should try to do on a regular basis.
MR. HOUSTON: I think it is valuable, because I think for those of us who are focused on one or two committees, understanding some of the priorities of the other committees in a structured setting is helpful. I am a privacy person and I don't think about populations, but when you get into a dialogue with somebody from populations about the things that are important to them, it is helpful to understand and help frame what you are trying to do. So I think it is valuable to get that interaction.
DR. COHN: And bring everybody together. Other comments on that? I see general nodding. One of the things that we are going to see over the next couple of years is, there is going to be a fair amount of transition on the committee. I think as part of that we will bring these, because I think they could be very useful to make sure that new members understand the issues before the full committee and come up to speed as quickly as possible.
So we will try to make sure that this happens as part of all that, and that it isn't trying to explain to a new member what is going on, but bringing them into some of the priority setting and conversations is a useful piece.
DR. VIGILANTE: It would really help the stimulation and ramp-up of new members.
DR. COHN: I think with that then, we will institutionalize that as part of yearly planning, and the Executive Subcommittee will consider exactly when and where it is appropriate in terms of future years.
We made it through three items of setting priorities. As I said, we will add this in and discuss it as we find moments today and we will have extended time if we need it tomorrow. But now John Loonsk has arrived. John, thank you for joining us.
What we are going to do is first of all ask John to give us an update ont the Office of the National Coordinator and new activities. Thank you very much for joining us on that. Then we are going to stop that and begin to talk about the NHIN report, which is not coming forward for action today, but is going to be being discussed. I will make some opening remarks on that, and then I will be asking John also to help frame issues before we get into the actual discussions.
For the NHIN report, we are asking Harry Reynolds and Jeff Blair, who are the co-chairs of the activity, to help lead us through that report. Hopefully we will begin to get started before lunch and then continue into the early afternoon.
With that, John, please.
Agenda Item: Update on Office of the National Coordinator
DR. LOONSK: Thank you, John. Good morning. Thank you to the committee for allowing us an opportunity to talk to you and give you an update on some of the work going on in the Office of the National Coordinator.
I have a few items that I wanted to touch on, then I think we may have time for some questions. The first is that there has been a very major activity in the federal sector related to the President signing an executive order for federal agencies that relates to a series of things. One aspect of it is advancing price transparency for those agencies that deal with health care provision. Another is around quality transparency. The third aspect of that executive order was around the use of standards in federal systems and in contracts and agreements that federal agencies make.
This is a recent occurrence. The executive order is freshly out. There is a lot of work that has to be done on the specifics of implementation and the discussion of progress and what will happen, but it does represent a significant step that identifies the intent of the Administration to indeed move forward with its walking the talk of advancing the area of standards, architecture standards, data standards and other activities in the context of moving forward with the national agenda. Secretary Leavitt has been very strong in his vision and support for this activity, and it is now manifest in the second executive order that the President has signed.
Turning to the American Health Information Community, there has been substantial activity and next steps being developed in the existing working groups. Each of the working groups having addressed its specific charge is now thinking of its broader charge.
As an example, the electronic health record work group had as its specific charge activities around lab result reporting. They are now turning themselves to the broader activities of electronic health records and doing a couple of things. They are starting to identify priority areas for short term activities, but also doing a broader, longer term visioning activity where they start to envision what that area looks like at the next steps of adoption.
So as we move from a limited adoption to a more substantial adoption and further down that spectrum, what are the implications of that for the types of things that need to be attended to in that domain, and how does that impact the various parts of the national agenda, and what things should be being addressed.
This visioning and priority setting is going to have an impact on the next round of use cases that will be developed and advanced for consideration by this large apparatus that includes the Health Information Technology Standards Panel, the next steps of the Nationwide Health Information Network activity, the certification commission for health information technology, as well as the considerations for security and confidentiality that are in a variety of different places in terms of those work groups and considerations, and the other aspects of the agenda that are working on different pieces.
The AHIC has already identified some priority areas for next steps. One of them is the development of an emergency responder electronic health record use case that was recommended by the EHR work group, and is being processed by the federal health architecture. There will be an opportunity for broad input into that, but the intent of that is to help to meet the system's needs of responding to Katrina-like situations in the future and other emergency situations particularly focused on the needs to be able to share patient information in appropriate ways in the context of emergency response and to be able to record health provision that is provided, whether it be in an evacuation center or some other non-routine circumstance.
AHIC has also identified the needs for more work in the quality area, and has identified the need to establish a new working group around quality and quality issues.
The other working group that has been put into place is called the confidentiality, privacy and security working group, which will be working on specific focused issues related to security, confidentiality and privacy as they relate to the specific breakthroughs. So the very practical need is, as the breakthroughs are advanced in the context of moving toward demonstrations and implementation, where is the set point on some of these issues relative to practical implementation.
This is the specific charge that has been given to that working group. That working group and the others are grateful to have the work of NCVHS as a predecessor to some of their activities, and are very much working with the documents that this committee has put forward in their consideration of some of these implementation related issues in association with the breakthroughs and the next steps.
The final large item that I wanted to mention, and there are other things going on as well, is that in October we are going to have the second Nationwide Health Information Network forum. The focus of this second forum is going to be on security and services. There is going to be discussion of technical possibilities as well as practical implementation issues and policy issues related to security needs of advancing the Nationwide Health Information Network initiative.
There will also be discussion of what health information network service providers should look like or could look like, what are the attributes of these service providers as they move forward as that market develops and as it advances in the context of supporting that broader activity, what are the services that these groups can and will need to provide and touch on as a little bit of an introduction to some of the ways that they can be situated to have an appropriate market for that existing as an activity.
The other aspect of that forum is going to be a furtherance of some of the discussion around the architecture variations. Those architecture variations very much relate to services and security.
The tenor of the forum is going to be involved with moving the discussion further. The first forum, we had a lot of broad public input, a lot of breakouts. We think it is still very important to have the public input, but we need to advance the conversation. So we are going to have a series of reactor panels in this second forum, where specific architecture variations are presented, where the different consortia describe the positive and negative attributes of those variations, where there is an opportunity to talk with some of those who are working in the field in terms of practical implementations by way of further contextualizing the issue and getting to some of the meaty decisions and discussion that has to occur in each of these different areas.
So it is going to build on the first forum, but also try to advance the discussion into more of the specifics, some of which the ad hoc working group has been grappling with in the context of thinking about functional requirements. So I think it is a very good pairing of the NCVHS ad hoc working group and the discussion at this forum in terms of advancing some of those issues as well.
There are three whirlwind examples of work that is going on. I would be happy to answer questions on them.
DR. COHN: Thank you. Mark?
DR. ROTHSTEIN: Yes, thank you for that overview. I have a question about the privacy issues. As you describe the working of the working group, it seems to me that the primary focus of that working group on privacy is to deal with the privacy issues surrounding the various use cases that are being worked on by the other working groups.
So my question is, are the broader issues of privacy that we have spent a lot of time working on here, are they being considered by some other entity or process outside of the AHIC process, or will they be taken up later by some working group at AHIC?
DR. LOONSK: I think the broad issues are very much on the mind of several of the different activities. In terms of the NHIN activity, we are trying to look at architecture solutions. There has been a lot of discussion of the Health Information Technology Standards Panel in terms of the standards for security. HITSP will be coming forward with its first launch of standards in the September time frame.
There are additional needs for security standards that exist beyond them. Some of those are very much in their mind, but are going to show up in the next deliverables in that regard.
But the context for the CPS working group if you will is to focus on the specific implementation issues contextualized to those breakthroughs. We think it is important that the work of NCVHS and other activities be taken and applied very specifically in a highly contextualized way to the practical needs of advancing those breakthrough opportunities.
As an example, the first thing that they are talking about and taking testimony on is going to be identity proofing and authentication methodologies. So taking a practical issue, trying to highly contextualize it so that there can be a set point if you will that is established for some of those activities, but it has to be done in the broader context as well.
So there are actually a number of different activities going on that relate to broad privacy and security and confidentiality issues.
DR. ROTHSTEIN: Thank you.
DR. COHN: Mark, maybe I should also remind you, we were asked by the Secretary to take the longer view of all of this. So this is actually a very good meeting of the minds.
DR. LOONSK: I think they are very compatible. I think there is a longer view activity here, perhaps a horizontal activity and a vertical activity, and we need to accomplish both of those things to move forward with the agenda.
DR. STEINWACHS: I was wondering if you might say a little more about the new quality working group and what their agenda is.
DR. LOONSK: I can try.
DR. STEINWACHS: Everything is quality, right?
DR. LOONSK: Everything is quality. There is certainly an aspect of quality reporting that comes out of that, but I think it is the intent of the group to look at some of the broader issues around truly inducing quality in the context of health information technology.
That being said, there are some practical issues that will come out of a specific charge and an immediate charge for that group to think about a subset of quality reporting metrics that can be tempered by the issues of what is accessible in existing health information technology systems, help to move forward with quality reporting that is coordinated, but also have it be practical in its implementation and to accomplish some of that.
So it is a challenge, to be sure, and the group has not met yet, and they will be helping to further detail in establishing that. But that is the broad content.
DR. STEINWACHS: Thank you.
DR. FITZMAURICE: Two questions. One of them deals with the work of ANSE, HITSP and the implementation interoperability specifications for the use cases given to them by AHIC.
They are about to deliver the implementation specifications. Do you have a sense of when they will be ready for AHIC review and recommendation to the Secretary? Not the time frame, but the sequence of events. For example, do we have to have implementation testing in a real life setting to make sure that they work before AHIC will be comfortable with them? Or will they go to the Secretary before then, and the Secretary will say it is up to the private sector to do the testing and tell us where you think we can give you further assistance?
DR. LOONSK: The first point to make is that the interoperability specifications from HITSP are not intended to represent new standards as they are to represent implementations of standards that have been worked through SDOs and have had a life and some level of implementation and consideration in that regard.
They are implementation level guidance, so they try to get to that level of specificity that is necessary to truly articulate in pretty strong detail how data exchange needs to happen, as an example.
The process that has been going on with those right now is that they have been shared for inspection testing by a variety of groups. The EHR VA, the federal health architecture and others have been brought in to look at those products to try to give responses in terms of the different attributes of them.
It is expected that these will be presented to the AHIC at the October meeting. There is still a lot of work that needs to be done, though. I mentioned the security work that needs to be done. These interoperability specifications have focused more by way of trying to parse the large tasks they have on interfaces, for example, versus on the security infrastructure and the security of data exchange versus the security of an organization that needs to be in place to support that data exchange.
We all realize there is much more to do in that regard. There is more to do in terms of the specific implementation. These will continue to be refined over time as they progress. But we expect them to be advanced out of HITSP and presented to the American Health Information Community in October.
DR. FITZMAURICE: My second question is, there is a lot of major thinking around this, because people are saying how are the use cases linked to the interoperability specifications, how are they linked to the NHIN functions, and how are they linked to the architectures proposed by the contractors.
I know a lot of this thinking has gone on inside of ONC. There was a conference in July where the architectures got exposed to the public and got public comment back, which I think was good. I think everything that ONC has done has advanced us at least two years beyond where we might otherwise have been, and we might not otherwise be here at this point.
Is there something coming up that will start linking these things together, or do you think the time for that might be next summer when we see just what we have in our hands?
DR. LOONSK: It is certainly the case that as products appear, the complexity of coordinating them gets higher. CCHIT has been working for some time. We now are close to having HITSP products.
As an example, those things have to be reconciled. We are working on methods of cross-coordination of those activities so that they can be. So for example, there is going to be a working group between CCHIT and HITSP to insure that the standards that are considered in certification are reconciled with the Health Information Technology Standards Panel interoperability specifications.
We also see deeds such as that, although the NHIN architectures are perhaps at a different stage of development, to cross coordinate, as you suggest in that regard. We think the use cases are helpful in that regard, but one of the other things we are considering -- there are a few activities at the NHIN forum that I didn't mention in the high level articulation. We would like to have the work of NCVHS represented there. We would like to have an opportunity as well potentially to have the standardization needs of these architectures discussed to get at some of that cross fertilization.
Each of these different pieces will have different needs for coordination, though. The NHIN consortia for very different groups working with other partners, it is not quite as easy to have a working group as a method of cross-coordination in that regard. But we are looking at different mechanisms to make sure that the different pieces are working together.
DR. FITZMAURICE: Thank you.
DR. COHN: John, I want to thank you.
DR. FITZMAURICE: I want to take somebody else's question who didn't want to ask it. That is, in going through a lot of the standards we get the same patient demographic information, for example, or how to use names, addresses and phone numbers. Has there been any thought in ONC to developing a data or information model that says, HITSP or somebody has said, here is a standard for this; we want to use this box of patient demographic information for all of our use cases where it is applicable, and then maybe there is a security box or a privacy box that you can begin building these blocks that don't have to be duplicated by all the vendors and all the SDOs.
DR. LOONSK: There actually has been a lot of thinking about that. That was one of the areas that was teased out as crossing many of the different breakthroughs.
There is an architecture component to that, and there is a data component to that. One of the subjects for discussion at the next NHIN forum will be data matching and technologies for data matching. There is a natural affinity to the data that are needed for data matching. Part of what we would like to tease out is in the context of standard needs for architecture, what are the different elements that need to be advanced to HITSP in a coordinated fashion so that they can be addressed for certain multiple purposes.
It is not clear that if you think about a functional area coming out of AHIC, that all those things are immediately considered in that regard. So we are trying to in this next round of use cases refine some of the elements and induce -- if you think about it, the use cases have had data issues, they had policy issues, they had process issues, they had architecture issues, and other things in them. We would like them to be that rich again and to potentially then do a matching with those needs that have been teased out so that we can get some of these common things addressed as well.
DR. FITZMAURICE: Makes sense.
Agenda Item: Ad Hoc Work Group Letter - Nationwide Health Information Network
DR. COHN: I think that question provides a wonderful transition to talking about the NHIN report, so thank you.
DR. LOONSK: You're welcome.
DR. COHN: We didn't even pay you for that question. I realize we have a half an hour before lunch, so I think what we are going to do is begin to discuss and hopefully begin to frame the document.
I just wanted to start off by reminding everyone, and thanking the people that have been involved with the ad hoc work group, which of course I had anticipated dissolving at this meeting, but probably will dissolve in November instead. But I wanted to thank the co-vice chairs, Harry Reynolds, Jeff Blair, the committee members and the work group members who have been working all summer. Mary Jo Deering, our lead staff, who worked with us much of Labor Day weekend to try to get to where we are right now. People like Steve Steindel, Linda Vaschetti, who isn't here, who really helped make all this happen, and of course our consultant, Margaret Amatayakul, who is here today with us after some interesting flights last night from Chicago, but was able to help us synthesize this into what we think is a very interesting report coming forward.
As I mentioned earlier today, cooperatively with John Loonsk I agree that this document really does need a little more public airing. We have had open conference calls, but I think up until today nobody in the public has seen this coming together as a report, as opposed to a group of appendices. So we thought it was probably a little premature to come forward with the final report without the opportunity for more public comment, both in open calls as well as at the next ONC forum, which we are going to be happy to participate in to help finalize all of that.
So we have talked through this one, focusing a lot on the last half of the document, but we do want to at least frame things a little bit.
Before I finish, I do want to make one particular point. That is to thank John Loonsk for his participation and involvement. We think that in production of reports like this, it is critical to have the involvement of the main stakeholders. I think his involvement in this and his input has really resulted in the production of a very good document, but now will continue to be refined over the next while.
So as a committee we want to thank you for not just giving us the assignment and then walking away, but staying involved in it as we have gone forward.
With that, and before I turn it over to Harry to begin to frame the report, John, did you have some particular comment that you wanted to make about the report and help with the framing?
DR. LOONSK: Yes, I did, Simon, thank you. I did really want to thank NCVHS, thank Simon, Harry and Jeff for their leadership in moving this forward, thank the working group. This has been a challenge. It has been a short amount of time. It is a great amount of work. There are some really complex issues that are embedded underneath it.
I think that Margaret has done a wonderful job in terms of documenting some of that complexity. I think it has achieved a level now where we can both see the architectural variations, but also see it begin to move forward with articulating what this environment and this initiative can look like.
So I wanted to thank the group. It has been a substantial challenge. I think I have seen an amazing amount of work put in and an amazing amount of accomplishment in a short period of time in getting to this point. So kudos and thanks.
DR. COHN: Of course, that will probably be more appropriate in late October when we all finalize this report. Hopefully we will all feel that way and remember this comment in the next six or seven weeks.
With that, Harry, do you want to open the discussion?
MR. REYNOLDS: Yes. What we are going to do is take you through the document, some sections. I will tell you that process, then I'll let Jeff make any comments he wants to, then Margaret and I will walk you through this and deal with any of your issues. We will go through the first ten pages first as a group, give you a framework of what it is, talk a little about the appendix, and that will be very quick, then we will get into the actual key sections of the document, starting with observation and recommendations on page ten, and we will take you through those.
So that will be our approach. We will get to where we can by noon, and then we will proceed as we come back.
As John said, it has been quite an effort to get to a structured document that can explain this complex and diverse subject. I think, Mike, to play off of your earlier comment, you will see the testimony from our matching patients to their records is in here, addressing those kind of things. So we have tried to synergize this thing into some of the recommendations we made earlier, plus others.
So Jeffrey, I'll let you make any comments you would want to, and then I will start us through the letter along with Margaret.
MR. BLAIR: Thank you, Harry. Let me just echo all the thanks that Simon has just articulated to all of us that have been working so closely together on this.
The only thing that I might add just very briefly is that we are entering a stage now where we need folks to carefully, thoughtfully and critically review what we have so far, to give us feedback for what might not be understood by other people in the health care industry.
So the only thing I am going to do with my comments is call your attention to the five sections that precede the appendices. The first one is the introduction. The second one sets up the framework. The third lines up identifying the minimum but inclusive functional requirements. The next one goes through the gaps policies and standards, and the last one is the next steps.
The only thing that I really ask, and that Simon and Harry and I ask, is, we really would love to have your thoughtful, critical comments on this. If there are pieces you don't understand, please communicate back to us either audibly or in the next meeting or by e-mail or whatever, because you are probably one of the best audiences to help us move this into a document that the public as a whole can understand.
That is all I have to say. Harry, thank you.
MR. REYNOLDS: Here we go. We will start on -- Jeff went through a brief discussion of the page two, which was the table of contents, but I will have you note the number of appendices.
A lot of times, appendices don't mean anything, but if you look at Appendix D, which was the 977 requirements that we looked at, and then you look at Appendix E, where we tried to turn it into 112 reasonable discussion items, then you will see as we have proceeded forward, we now have turned that into a set of about 15 observations and recommendations, lumping all these things together.
But these appendices are important for you to look at. In some documents they just kind of are in there. This also gives you the value of understanding where it started as far as what we got from ONC, and then where it is as far as our dual workings to get down to where we are.
Although the recommendations may seem high level, backed by all this data that is in this document and in these appendices, you are talking about real stuff, and you are talking about something that is going to make a real difference. So I ask you to not just gloss over the fact that there are appendices in this document. They are important in how we built the body of the work. So really take a look at them if you would.
On page three we get into the purpose and scope. I would agree wholeheartedly with Jeff. We can neither -- out of this we neither want a document that makes the people that are real close feel good only, or the people that are real far away feel good. It needs to bring everybody into a center discussion point, so that people really get it. Somebody ought to be able to pick this document up and get it. Then they can go as deep as they want to in the appendices to get down to the depth.
So that is what I think we have tried to put together here and tried to create. So as you read it look at it, especially as you listen today and give us any further input. Please read it with that. If you get lost, let us know. If there is a section in here that takes you somewhere you can't get yourself back to, let us know, so that we make sure we create a document that plays in a significantly larger population than this room or even the sessions that ONC has put on. This has got to play in the world of public view.
The purpose and background, I'm not going to spend any time on that. Intended audience. I think the first sentence there on page four on intended audience, this is a broad audience. This is not just for the people in the know. This is how does it really work.
We get into on page four the framework, what is the importance of it. I think what we did on page five, we tried to put down four basic examples of real world opportunities where this would exist. Again, we have talked many times in here, especially on the privacy letter that we did, what is the NHIN. We are trying to put together some policy thoughts on what is the NHIN.
When we tried to talk about some flows here on page five, that will give you the sense that this is the kind of things that it may help deliver, not totally defining it.
If you go to page six, I think two key items that we want to point out on page six is, it is really a system of systems. This is not a central entity, this is not a central situation, this is not a government brick and mortar that everything flows through. This is a system of systems, both in the public and private sector. It can be whatever it is.
Then, Simon touched on it, John touched on it, differences in design and service. The four contracts that they have let, totally different parts of the country, totally different systems, some already existed, architectures work. They interoperated as they did. So you are going to have many disparate views of how to group up, whether it is RIOs or whether it is non-RIOs, whether it is a vendor, whether it is this or whether it is that, and trying to pull those together and realizing that there are those differences.
I think I would have you note some key sentences toward the end of that paragraph under differences and designs. The fourth line from the bottom, over time it may be necessary to reduce the number of variations for greater efficiency and effectiveness. We talked about the HIPAA standards, we have talked about others. We are building this thing as it goes. We are building it with base functionality. You may see that becoming a lesser set of disparities in total, not going all the way out and telling somebody exactly how they may have to do every Nth degree of what they are doing.
As John mentioned, in his next offsites that will be an area of focus as to how many are those and what might they be and what might be done with it. So that will be the next helpful step in drilling down on this document further than it is.
The next thing I think you need to look at is a discussion of terms, which starts at the bottom of six and the top of seven. The reason that I say that is, the hardest part that a lot of us got -- and I'm going to show you one particular term on the next couple of pages; when you use a term, everybody hears it differently. So please, as you look at this document and you think of this document, look at these terms so that you understand what we meant by the terms.
I would make one key point on that, if you would go to page nine. There are three words: certification, registration and then the magic word, credentialing. You could find any physician in the United States, and as soon as you said credentialing, he wouldn't be thinking about the NHIN and he wouldn't be thinking about anything related to the NHIN.
The problem in the health world now, there are terms of art that people have adopted in many different ways. We have tried to very carefully in this section seven, eight and nine make sure that we have clearly identified what we mean in this document. So as you are reading it, stay close to this definition. Remember, we are grouping people that don't know anything about it and people that have been in it to the 977th requirement degree, and trying to bring them together and have a discussion with them both in the same room. But please stay with these words. These words are critical as you look at it, to try and understand the message that we are trying to deliver, not necessarily the total proper use of that term in somebody else's form somewhere else. I think that is really critical as you look at this document and go forward.
Now let's go to ten where we are going to get you to start listening closely, and hopefully signing off at a later date that these are the observations and recommendations that NCVHS is going to want to do. On page ten we talk about the organization of our recommendations. We mention again that there are designs of services and this whole architectural difference. We just reiterate that again, because that continues.
If somebody reads this and doesn't see their design or their architectural belief or their anything else, then people start getting a little bit nervous. So we have identified that.
Recommendation zero, I won't read that, but we are just basically saying we feel there should be a good set of these.
Now let's get into a little bit deeper discussion. The first item that we want to talk on page 11 is certification. What I am going to have Margaret do is read the observation and the recommendation, and then let's have a little bit of discussion on your feelings about it. We don't expect a lot of you in this room to be experts yet, but if you have anything that jumps out at you that we may need to do further work on, or something that you don't understand, or something that strikes you in different ways, this would be a good time to start.
This is what we are going to ask everybody at some point to sign off on, that this is what NCVHS working with ONC recommends to the Secretary and on to the general environment. So Margaret, if you would go ahead and read observation one, that would be great.
MS. AMATAYAKUL: Harry, just as a point of clarification, do you want me to read the actual statement as well as observation and recommendation, or just observation?
MR. REYNOLDS: Just observation.
MS. AMATAYAKUL: The NCVHS notes that the initial development of network certification criteria is part of the 2007 deliverables from the CCHIT. NCVHS envisions that the certification process will accommodate appropriate variations by location and system capabilities and enable changes over time. For example, some organizations that provide certification for entities to participate in in the Nationwide Health Information Network may provide specific services that entities in a local community may desire such as message handling, terminology, mapping or repository functions. At some time in the future, these entities may prefer to perform these functions themselves.
Recommendation one. The NCVHS recommends that CCHIP insure that appropriate variations by location and system capabilities related to certification can be accommodated, and that their ability to change over time is assured.
MR. REYNOLDS: This one points out, there are groups that are already working, and John has mentioned those as well as others. So trying again to build off of existing standards and build off of existing structures that have been put in place is what we are trying to say. Any comments or questions?
DR. FITZMAURICE: Does this also refer to the fact that in order to certify somebody, you have to know what their system has, and there ought to be a standard way of describing the capabilities of that system so that you can match up electronically a profile of the receiving system, so that you can match that up with the network requirements and see automatically, does this system conform with what the network requires to exchange information?
MR. REYNOLDS: Comments from anybody on the committee about that? I'm not going to position myself as the answerer of all questions. So those of you that have been heavily involved, I will be your net of last resort.
DR. FITZMAURICE: What this raises is, if we advocate local variations, we should also advocate ways of describing them so that they can be automatically adjudicated, rather than having an eyeball for each applier.
MR. REYNOLDS: Margaret, do you want to comment?
MS. AMATAYAKUL: The global recommendation is that each of the main points and sub-points be adopted as the set of minimum but inclusive functional requirements. So under 1.1 above, the certification should describe the level of participation for which these systems are capable.
I think that is what you are getting at, but if we need more, it is not clear.
DR. FITZMAURICE: The network can say, here is what we need. The edge systems should fit their list of capabilities so that it meets what the system requires to work automatically. That is the point I am making. For advocating a lot of local variations, that probably means we are advocating a standard way of describing those local variations, so the system can handle it automatically.
MR. REYNOLDS: Anybody else want to comment? I have got a comment, but I do want this to be the committee's opportunity. John, anybody else?
DR. LOONSK: I could add that there are some very practical aspects of each of the prototypes that relate to ways in which organizations and at times individuals would authenticate to a health information network service provider and identify what they are capable of doing, or at times what data they may be able to share based on what their capabilities are. That is a very practical aspect.
Clearly there is another level of this, which is about suggesting that there needs to be a practical certification capability and testing capability for those certification criteria to allow for participation.
I'm not sure that the former is as much the target -- the practical needs of the former is the target for this as the latter.
DR. STEINDEL: Thank you, Harry. This recommendation, and there are several others that are very, very similar, puts some sort of charge to other organizations like CCHIT and HITSP that have their own types of mechanisms for putting together what their criteria are going to be.
My response to Mike's question, which I think is totally appropriate, that we should be developing some type of meta data or transaction type standards to say what these networks are capable of, I really feel the recommendation as stated here is about as complete as we can make it to CCHIT. But Mike's comment with regard to how far CCHIT should go is a very appropriate comment to make to their process and their certification.
DR. FITZMAURICE: Assuming that CCHIT is the adjudicator for the NHIN. I would accept it.
DR. STEINDEL: Well, my comment to that is, they have the contract right now to develop certification standards for the network. So whether they will be the absolute adjudicator or not, they are going to be the initial adjudicator.
MR. REYNOLDS: One other comment, Mike, and I think you make a great point. The other thing is, when you look at some of our definitions about entities, there are so many different levels of players that are going to be involved in this that as this becomes clearer and clearer, what is the least common denominator and what would their requirements be. Then as you go and do a RIO, they may take every one of these and have to fit these requirements. There is also going to be another filter that is going to be put in.
So who you are as an entity and how you want to play is also going to decide how many of these requirements and capabilities you have to have to deliver it to the people on the other side while you are interfacing to the network. So that is another challenge that is going to need to be addressed. Once those are set, then each entity is going to have to look at it and decide how many they want to play in to offer whatever service they would want to offer.
MR. BLAIR: One of the things that frankly would be helpful to all of us who are working on this group, and both Steve and Michael have been -- and when we ask for feedback, Michael comes up with some very appropriate ones, and Steve sharpens it some more. I especially want to invite those of you who have only had a chance to glance at the document, and maybe even some of you who hadn't seen it before.
There are some terms in here, like appropriate variations. If you are lost, please tell us. Tell us how you are reacting. I really would like to hear from you who look at this document for the first time.
MR. REYNOLDS: You will have the opportunity for the next couple of hours, so we won't drag you out into the middle. But we will be coming after you continually.
Let's move on to authentication. Margaret, while we are getting started on some of these, maybe it would be better to go ahead and read the definition, because as soon as we skipped the definition on the first one we had to go right back to it. So let's -- we'll learn on the fly here, so why don't you go ahead with that, and then we'll see.
MS. AMATAYAKUL: Authentication. Enable authentication of an entity as users, system software tools and individuals, as well as independent users whenever location of information and/or data are exchanged within a Nationwide Health Information Network.
2-1. Enable an entity to register or provide authorization and establish authentication processes for users to connect with a Nationwide Health Information Network in a manner consistent with all HIPAA and other applicable federal, state and local privacy and security legislation regulations, including national provider identifier and national plan identifier.
2.2. Protect authentication credentials during transmission.
2.3. Provide mechanisms for non-repudiation when policy would require such service.
Observation. Some testifiers to the NCVHS suggested that only local entities should authorize and provide authentication for their users, and that authentication should not be a network function. The NCVHS observes that there is a difference between where an entity would authorize and authenticate its own users and where an independent user such as of a personal health record would grant authorization to share data and need to authenticate to a network. See also number three below.
Variations in where authorization and authentication of systems and individual users, both aligned with an entity and not aligned with an entity, take place seem compatible with the goals of a Nationwide Health Information Network. The NCVHS also recognizes that policy matters are the subject of other groups working on the Nationwide Health Information Network initiative.
Recommendation two. The NCVHS recommends that HHS ensure that the current development of policy for participation in a Nationwide Health Information Network includes appropriate authorization and authentication processes.
MR. REYNOLDS: Comments, questions?
DR. FITZMAURICE: On this one, I would add after authorization and authentication processes, I would put and profiles, because the nationwide network ought to be able to recognize who has given such authorization and who has been authenticated in some ways.
So the process happens maybe at the local level, but communicating the meta data that has happened and here is the level of such assuredness, that seems to be a standard that we would want to carry through the NHIN, so that somebody at the other end could receive it and say, I guess they meet the same requirements that we require.
DR. CARR: Harry, first let me say that this is an unbelievably fantastic document. I learned so much just by reading it. You have already made it very easy to understand.
One of the things that you have done in a couple of areas is give examples. I am wondering to your goal of having a broader discussion here if you could just take each of these and say, so for example, if you are logging on and you are this person, whatever is happening. I don't know if you could do that, but it would help to let us all think about the practical applications.
MR. REYNOLDS: Let me try one on authentication. Remember, there are plenty of people around here that can help. Does anyone want to take this one first?
For example, Justine, you are a physician at your hospital.
DR. CARR: Yes, I am.
MR. REYNOLDS: So for example, there may be the capability that your hospital becomes authenticated and then vouches that you are one of the viable users of their system. Or as we also said here, and this is why this thing is so broad in its impact, if somebody has their own personal health record and want to share that, and I am going to play off something Michael said, there is no NHIN, there is a system of systems, wants to play in that world, then how do they authenticate that they are somebody real that should be giving out that information that they are there.
So remember, we are not down to saying exactly how yet. We are saying though that it has to play across all these differences, so that when a doctor is asking for somebody's records, or somebody is saying that their records can be sent, who is who, what does that mean and how does this play, is really what this has to get down to and where the rubber meets the road. It is the same kind of thing that we all have dealt with in our own institutions.
DR. CARR: What is helpful on this is, if an individual wants to generate their own personal health record information, talk about identity theft, somebody could make up information on somebody else, you are saying that has to happen. I think we are accustomed to thinking about it from the provider point of view, but this is a new dimension.
MR. REYNOLDS: It is, so that is why this is a subject that is paramount to this, because who is who. No different in the Internet than anything else we deal with.
DR. STEUERLE: Justine, were you suggesting that some of these examples be added to the document?
DR. CARR: No. I'm just saying, if Harry wants to stimulate discussion, for me anyway, I have to picture what we are talking about.
MR. REYNOLDS: We will try to do that, and at least give you some reference as to what it is.
DR. TANG: I think under the new process ground rules that we are allowed to suggest wordsmithing changes if it is on a recommendation, for clarification. So may I --
MR. REYNOLDS: Yes, a clear and precise change under the rules.
DR. TANG: I'll let you be the judge.
MR. REYNOLDS: I will be the judge.
DR. TANG: The part I didn't understand as much is the phrase, the current development of policy. Could we say that NCVHS recommends that HHS insures that certification for participation in an NHIN includes appropriate authorization and authentication process?
MR. REYNOLDS: Does anyone have a problem on it? Okay.
DR. VIGILANTE: Mike offered this addendum offering and profiling. I don't know where that meant, but does that word mean to everybody what you explained it to mean? Because it didn't to me.
DR. FITZMAURICE: It is not obvious.
DR. VIGILANTE: Right.
MR. BLAIR: I think he said, does profiling mean the same to everybody.
DR. FITZMAURICE: Yes, it is asking the question. It is probably not obvious. We may need to have a sentence that says a profile is a statement of capabilities expressed in a standard form.
MR. REYNOLDS: If we end up adding any of these, back to the term art. If any of these get added at any point, they will need to be added to the definitions, so that any time we use a word like that -- profiling in an open forum is a very scary statement.
DR. COHN: It actually isn't profiling, which has a whole different meaning. This is profiles. I have heard Michael now on two recommendations really talking about meta data. That causes me to wonder. I don't know if we want to go there or not, but I think that is what the subtext has been here.
DR. FITZMAURICE: It is having a standard for the meta data that says yes, somebody is asking for information from my system, yes, they are a medical doctor, yes, it is for the care of a patient, okay, I released it. That might happen at four o'clock in the morning. It is their system calling mine, but because they have this profile, my system lets them do it. Then I can defend myself under HIPAA, saying it was reasonable for me to do it because we have this standard. I understood what they were asking. If they were posing as an imposter, I did everything I could that was reasonable.
DR. VIGILANTE: Shouldn't authentication include that? Do you have to really specify what authentication means? Don't we mean that when we say authentication?
DR. FITZMAURICE: If all the places around the United States are doing that, there ought to be a standard way to express it, so that we know what each other means.
DR. LOONSK: One of the things that John has been very strong on, and there has been an amount of discussion in the group, is the consistency at the level of what the work is. I think it is helpful.
I think that it is true that the needs of profiles in this regard are manifest in the functional requirements that are described. It is more of a technical need that is to accomplish that goal. I am comfortable that that is in there.
DR. STEINDEL: Thank you, John. That was one comment that I was going to make. I agree with you.
I am really commenting in part, and was going to build in this comment to Paul's comment. I don't think that this recommendation involves certification. I think this recommendation goes deeper than that. Certification is a test to see that you meet the requirements of the policy that exists.
I think what we are saying here is, that policy doesn't clearly exist now, so we can't develop the test for these processes. We need to know what level these services need to be validated before we can give it. I use the term, and John the first time I used it had a snicker. Before we give people a ticket to ride on the NHIN, we have to have a certain set of policies that they meet to get that ticket.
I think what this recommendation says is, that is what needs to be developed, in a uniform fashion. Then attached to that gets to Mike's comment. Obviously once we develop those policies and those requirements, and this goes for the first recommendation and this recommendation and many other recommendations, we do have to have a mechanism to transmit to the people what they say they can do. There has to be meta data associated with it. But I don't know if we have to specifically enumerate that in each one of these.
DR. WARREN: I wanted to comment also on the thing about profile. I agree with John. For me, on the recommendation a process contains a lot of different things, and it could contain meta data, it could contain profile.
At this point, I don't think I want to specify that a profile be created. There might be other ways of communicating the same data that we don't know about yet. So I would rather keep it cleaner and just identify processes and not put profile in there.
MR. HOUSTON: I echo John's comments. There are a lot of requirements that underlie what I think we are trying to distil down to some very high level recommendations. I think we have to be very careful about trying to express the comment in a global way while not trying to in certain cases drill down in the recommendation in minutiae detail which may not do anything other than confuse the broader purpose.
So again, I agree with Steve going back to the original recommendation, but we have to be very careful about recognizing the level at which these recommendations are made and all the detail which is already behind them. Maybe what we need to do is -- it would be nice if we had the recommendations with us; if somebody had a question, we could go into it and say it is already here, but I think you have to assume some of that as we are going through this.
MS. AMATAYAKUL: Actually, it is already here in the 6.3, line 627 on page 14, enable standard information meta data to be included in data retrieval, delivery of messages in order to convey sensitivity restrictions and individual permission and entity preferences.
MR. REYNOLDS: That's good. One comment, and then Simon, from a process standpoint, this would probably be a good place to stop.
From a process standpoint, we are asking people for input. I want to be careful that we discuss the input and we write it all down. We need to pull all this out. Even if we think we have got the answers to it, I want to make sure we are not point and counterpointing and then we are going to shut down what comes in.
So anything that is said, remember, we are all still trying to work this out. So we have got a document here, but we don't have it all figured out, so please keep it coming. No matter what the discussion is, please keep it coming. That is what is going to be hugely important as we prepare this document.
DR. COHN: With that, I was going to give people a lunch break, because I thought it was a good place to stop.
(The meeting recessed for lunch at 12:11 p.m.)
A F T E R N O O N S E S S I O N
DR. COHN: Why don't we get started again. Harry, I'll turn it over to you. I think we are on to item three, authorization.
MR. REYNOLDS: That is correct. We will move right through these. Margaret, why don't you cover number three.
MS. AMATAYAKUL: Number three, authorization, facilitate management of an individual's permission authorization to have information about location of health information shared or apply restrictions on access to specified health information.
3.1. Enable entities and/or users to provide permissions, authorizations and/or restrictions to share location information or data. Enable changes to be made in permissions, authorizations and restrictions as requested by applicable entity and/or user. Allow access to location of information and/or burden of disease only on permission, authorization, status or emergency access as defined by law. Utilize HITSP's identified standard authorization codes to convey permissions, authorizations to share data.
There is a footnote that those authorization codes need to be developed, and we have a recommendation later on that.
3.5. Enable participants in a Nationwide Health Information Network the ability to anonymize and relink data to insure its confidentiality in accordance with policies of the relevant entities, for example, public health departments.
3.6. Enable an entity to de-identify and aggregate data for research or other purposes upon request.
The observation is that the NCVHS refers readers to its recommendations to the Secretary of HHS on June 22, 2006 regarding an individual's participation in a Nationwide Health Information Network.
Recommendation three. The NCVHS recommends that HHS adopt positions consistent with the NCVHS recommendations of June 22, 2006 regarding an individual's participation in a Nationwide Health Information Network that A, the method by which personal health information is stored by health care providers should be left to the health care providers. The individuals should have the right to decide whether they want to have their personally identified health records accessible by the NHIN.
This recommendation is not intended to disturb traditional principles of public health reporting or other established legal requirements that might or might not be achieved by an NHIN. Providers should not be able to condition treatment on an individual's agreement to have his or her health records accessible by the NHIN. HHS should not enter the development of opt-in/opt-out approaches, consider local, regional and provider variations plus evidence on the health, economic, social and other implications, and continue to evaluate in an open, transparent and public process whether a national policy on opt-in or opt-out is appropriate.
E. HHS should require that individuals be provided with understandable and culturally sensitive information and education to insure that they realize the implication of their decision as to whether to participate in the NHIN.
MR. REYNOLDS: Any comments? One point I would make is, obviously this was picked up from an earlier body of work. As we continue through this whole process, as more and more of our own recommendations plus standards and other things come to be, as these documents progress, we will see more and more of this in them.
Questions?
DR. STEUERLE: Just a minor comment on the opt-in/opt out issue. As I remember our prior discussion, we tried to make clear -- and it is not mis-stated here, but I wonder if it might be made clearer that the opt-in/opt out might lead to different choices for specific subsets of information.
You already have exceptions for national health reasons, for instance, but there are some cases where it might only be opt-in for the whole record, but it might be opt-out for specific subsets. So I'm not trying to decide that. I'm just wondering if you might want to make that clear here with some slight clause.
MR. HOUSTON: At the beginning of the recommendation number three, we already referenced the earlier recommendations from June 22. I think if somebody is interested in delving deeper into them, maybe they just go to those recommendations and review them, is maybe a way to bridge that gap.
MR. REYNOLDS: Any other comments? Let's move to person identification. As you listen here, this is where we also use the matching patients to their records testimony and everything that we heard there, so you will see that in other pulling in of previous bodies of work by this committee.
Margaret, go ahead, please.
MS. AMATAYAKUL: For a person identification, utilize a HITSP standard person identity information correlation process to uniquely identify an individual.
4.1. Uniquely identify an individual through matching on various identifiers such as last name, middle name, first name, date of birth, gender, et cetera. Utilize an automated process to resolve identity ambiguities.
The observation is, successfully matching individuals to their health information is essential for the functioning of a Nationwide Health Information Network. Most entities collecting and maintaining health information have implemented master person indices or an enterprise-wide NPI to accurately match individuals to their records. A set of demographic data is used for this purpose, although each entity establishes what demographic data matching process or algorithm to use.
Although there is a high percentage of correct matching at the entity level, adjudication of non-matches is labor intensive and time consuming. There are also variations in the need for a perfect match versus a near-perfect match. For example, the standard tolerance for error may be less stringent for certain kinds of research and administrative uses and much more stringent for health care delivery.
When two or more entities exchange health information without a standard set of matching data and matching algorithm, the risk of mismatching individuals to their health information increases. Testifiers recommended various automated and manual processes for resolving identity ambiguities. The NCVHS observes that the DoD and the VHA are working together to test an automated process that results in accurate record matching to enable the transfer of health information from the DoD to the VHA.
The recommendations. The NCVHS recommends that HHS should identify and recommend minimum criteria for successfully matching individuals to their health information, including that A, ONC continue to provide national leadership and direction for the purpose of accurate matching of individuals. The work being conducted by the consortia contractors to identify matching identifiers is one example.
The NCVHS stands ready to assist with further analysis of testimony heard during 2006 as well as its experience with vital and health statistics data as another resource.
B. That data sets be created for use by entities for testing and accuracy of their matching methods.
C. That the results of the DoD and the VHA processes to accurately match individuals with this health information be evaluated, including technical, financial and social impacts for adoption within a Nationwide Health Information Network.
MR. REYNOLDS: This plays a little bit, Michael, on your earlier comment on profiles and some of the other things. When you start creating data sets that people can use to start doing their matching and things that are put in place for all these different things, allow people to come to a single place to figure out a single approach on how to do things.
Any comments?
MR. LOCALIO: I'm not sure if I have a comment as much as I have a question. When I read this, I said I really don't understand what is going on here. It seems to me one of the issues is, we are talking about having to introduce a system for linking part of a person's record in location one with a part of a person's record in location two for the purposes of patient care, is that correct? Then having to use, for example, last name, middle name, first name, date of birth, gender, in order to be able to determine whether location two belongs to the person you have in front of you.
I think this is an important issue. I think it is dangerous. When I lived in Minneapolis, there were 22 pages of Andersons in the phone book. So in some locations this is an issue.
Now, it seems to me, the last time we discussed this, the issue of a unique patient identifier came up, and of course there are certain people who work in this town who are dead against it. But this strikes me as being a crucial problem, and how you link the pieces up by something other than names and date of birth, where you may have to get into something beyond exact matching. This is like a fundamental problem of how you put the pieces of the puzzle together.
So I guess I don't understand why -- let me put it this way. I can't understand why you would make a recommendation like this one. It seems to me that the real recommendation should be, folks, if you want this to work, you have got to have an identifier for people so this works. Otherwise you have got serious problems.
MR. HUNGATE: I wanted to comment in the same vein. As a patient I would demand that I be properly identified. If it means that I have got to have an identifier that was a biometric source in order for me to be identified correctly, I am willing to do that.
MR. LOCALIO: -- opt in on this, so it is not as if we are dragging people to the office and saying you have got to do this. This is for somebody's benefit. So if somebody is going to be participating in this, I should think most people would understand the need to know that the medical information on your heart has to be exactly linked to the medical information on your liver if they are in two different locations, so you don't end up being treated for somebody else's liver.
MR. REYNOLDS: Simon, you had a comment?
DR. COHN: Yes, I did. I am reminded about why the original letter didn't make it into the committee last time. I am also reminded about our privacy letter. There are some things that there is clearly not committee consensus or certainly not national consensus on.
But I just wanted to reflect on a lot of the testimony you received about matching patients. I think we heard over and over again that yes, you could do everything you were describing, but it still wasn't sufficient. You still needed to do a whole variety of matching things, because people mis-transposed numbers, they reused numbers, on and on and on. A number is just an additional way that you help assure that a person is who they say they are, or that the data represents that person.
So I think what you are describing is a different set of issues, as opposed to, let's make absolutely sure that the data is about that patient.
MR. LOCALIO: I understand exactly what you are saying, Simon. You don't rely on somebody's medical record number alone. You say you have a medical record number, it could be wrong, it could have been changed, and you have got to be sure that this is a male and this date of birth.
So you use other factors to supplement a unique identifier, but are we talking about people not wanting to have a unique identifier, other than last name, first name, middle name, date of birth? Or are we talking about the option -- are we discarding the possibility that NHIN will have to have some formal unique identifier in addition to these factors here?
MR. REYNOLDS: I think we are addressing it in a couple of ways. ONC has got some test cases out there right now. You have got four major consortia groups working on this right now. They are getting results. The DoD and the VA are working on some kind of matching material. We heard a lot of testifiers talk about how it could be done with or without some kind of a unique identifier.
Now, you can shake your head, but they were honorable groups, one of them being the Social Security Administration and others that were doing it. We heard a lot of discussion that more and more people were using the same social security number in their households.
So we have had this debate over and over again, and we went through it in our letter. Our recommendation is that this needs further study, that this needs close scrutiny. If whatever comes out doesn't have the right degree of sensitivity to where you get a 30 percent error rate; we heard everybody that testified to us say the difference between a unique identifier and not is about between 95 and 98 as a percent of match. So we heard some pretty talented groups that are looking at a lot of records come up with this.
So we are recommending that this is not a done deal. This is not a clear and precise field yet. Until we get more information and others give us more information, we recommend that this continues to get that kind of work. We are not saying not and we are not saying yes. We're saying it needs continued focus.
MR. LOCALIO: Are we willing to make a recommendation on what type of error people are willing to tolerate? Ninety-five percent I would consider to be unacceptable, 98 percent I would consider to be unacceptable, 99.999, maybe a couple more nine percents, may be in the realm of acceptability to most people.
MR. REYNOLDS: One other comment. What we also saw -- and I think there are some administrative words in here that basically says when there is not a clear match, the information comes back in a way that somebody would have to select. You're not saying that if it is only 95, here it is, go with it. There are administrative procedures around that that have to be dealt with.
Obviously we have got a whole letter. Obviously we have pulled out the pieces where we think our recommendation is still where it needs to be, and that is how we are going about it.
John, you had a comment?
MR. HOUSTON: If I look at recommendation 4A, it in one sense implies that you have some type of matching criteria, but it really leaves it up to the ONC to decide how to do this.
I know I am in support of a national identifier, and I recognize the sensitivities towards it that have caused us to stay away from it, but 4A doesn't preclude somebody at ONC from going down that road.
MR. REYNOLDS: Nor does C preclude that.
MR. HOUSTON: Right. So I know there are a lot of people that don't want to touch this issue.
DR. VIGILANTE: So Russ, could your objection be addressed if in addition to name, middle name, first name, date of birth, gender, it was also at least considered the possibility that the national identifier might be entertained some time in the future? Not to say it that way, but that it is excluded there implies to you that it is off the table, never to be considered. By just mentioning it, you at least entertain the possibility that it might be.
MR. LOCALIO: Suppose the results were that you could never achieve the degree of matching that is necessary for patient care unless you had a unique identifier. I think that is a distinct possibility that we are going to have to face.
DR. VIGILANTE: I guess what I am saying is, we are not saying how you have to do it. We are just mentioning a variety of ways you might do it, and another of those could be including a national identifier, and we are not specifying one way or the other. Just by listing that as a possibility, would that satisfy your objections.
MR. LOCALIO: I don't have an objection. I just have a concern here.
DR. VIGILANTE: Then how do we address your concern?
MR. LOCALIO: I think the recommendation -- when I looked at it, I said this is naive. I think the recommendation has to face the reality that we must have exact matching with patient care, and that that may require some type of identifier other than what we have listed here.
DR. VIGILANTE: I would go back to my original comment.
MR. LOCALIO: I'm not talking about taking every baby when it is born and implanting a chip in every baby. That is the kind of thing that people don't like, including me. But if the NHIN is something people want to participate in in order to facilitate the coordination of care across the country or across institutions, to make that work, rather than having to send pieces of paper around in addition to this, you may have to have an identifier that goes along with that participation.
I think that is all I am trying to say here. It may be a cost of having this work. I don't know how to articulate that in this document, given external influences and comments that we all know about.
DR. VIGILANTE: It sounds like if you were at least open to mentioning that as a possibility, it would address your concerns, right?
MR. LOCALIO: Yes. By the way, it may be necessary to make this work to reassign participants an NHIN identifier, in addition to everything else that we have.
DR. TANG: This is either a comment or a question. Number 4.2 says utilize an automated process to resolve identity ambiguities. I thought the text said that probably this is going to require a manual reconciliation. I didn't know that there was an automated way of reconciling, once you could not uniquely dis-ambiguate patient information using an automated method.
DR. WARREN: That was not our intent when we wrote that. What this was is, there would be an automated process to link records together and to match them. When that is not possible, then it goes to a manual process.
DR. TANG: Correct. This almost says the opposite, I think. That is how it reads.
DR. WARREN: Is it the word ambiguity there that is throwing you off?
DR. TANG: Yes, result, identity ambiguities. I assume that falls out in the automated process.
DR. STEINDEL: Russ, it is kind of obscure, but recommendation 4C actually addresses your point very specifically, where we say the results of DoD and VHA process to accurately match individuals with their health information be evaluated, including its technical, financial and social impacts for adoption in the NHIN.
That is a very oblique statement. DoD and VHA not only use a unique patient identifier, but they are moving to the same unique patient identifier. So what is contained in that result is, we used this natural experiment that is going on within those two organizations to see what the implications are and how the people react to it, which is what we mean by social. If there appears to be an acceptance, then maybe we have a base that we can say yes, we can provide a more accurate match if you allow us to go to this.
So I don't know if we want to make it clearer, because as we pointed out around this table, there are political reasons for stepping cautiously in that area, but this is a natural experiment that addresses that point specifically.
MS. GREENBERG: That was one of the things that I was going to say, that their work that is referenced here uses a unique identifier based on the ATSM standard.
That segues into the other thing that I wanted to say, which is, I do think -- this is always the elephant in the room, but I do think it is appropriate to not have a separate letter on matching patients to their records, because it is such a -- as you say here, such an essential part of the functioning of an NHIN.
But I felt that the separate latter that had been drafted multiple times provided a pretty good summary of the testimony that was heard, and information on what this DoD thing was, on what adding social security number did to having these other pieces -- some of the things we have been talking about, was in that letter.
At a minimum, we could point people here to the testimony. We could mention, it doesn't even say here, I don't think, that the committee did separately hold hearings on this topic and did receive testimony from a number of groups who are working with this issue, and that that testimony is posted on the NCVHS website. It makes people plow through it, as opposed to having nicely summarized it the way that letter did.
I don't know if there is any middle thing between that, not doing the separate letter, but also not leaving people to their own devices, having more of a summary. We stopped doing full minutes of meetings. We have the transcripts, we have the presentations. We don't have a summary.
It was a number of hearings. We could possibly come up with just a factual summary.
MR. REYNOLDS: Let me let you finish, then I have a recommendation.
MS. GREENBERG: That is what I am saying. I miss that. I think that is available to people who are laboring in this area, and we should look into it.
MR. REYNOLDS: Margaret, why don't you take a note on this? Obviously there are a couple of ways to handle it. We could add some of those details to here in an appropriate way. We could also summarize that testimony and others and add some other appendix to point to, not making any recommendations in the appendix, but saying since this is an area of interest, here are certain pieces of information that were presented to us to help us build that recommendation.
So I think for purposes of our group, if we can make that as a note, realize that the committee wants us to consider more than we have here currently as a process, then obviously we have got a meeting of our subcommittee later today or tomorrow where we could take a look at this.
DR. COHN: I did want to point out on line 558 that there is a reference to the testimony that you heard as a part of the recommendation, just to comment on that.
MS. GREENBERG: It is really oblique, though. I didn't even get it.
DR. COHN: The other thing that I don't want to lose from what Russell was describing, which I don't see here, but probably need to note somehow, is the issue of accuracy, which to me is the end gain here.
What I noted was that in the policy area, to me that is a policy issue, like how accurate does this really have to be. It isn't surfaced as something that somebody is going to have to make some policy on.
DR. WARREN: In response to Simon's thing about how accurate do we have to be, we heard testimony on that. If it had to do with billing, then 95 percent accuracy was just fine with people. If it had to do with reports or sending out other information, 95 percent was just dandy. If it had to do about a clinical decision about a patient, it was not acceptable. What we heard was that physicians would not trust the information they were given unless they had 100 percent. If they didn't have it, they would go re-collect the data and do it all themselves, rather than make a judgment on data they did not trust for patient care.
So I think Russ is right on target here. It has to do with peoples' confidence in the data itself, but you have to figure out what you are using the data for.
DR. ROTHSTEIN: One minor point. If the language in recommendation four or subparts is rewritten, there is an argument that I would suggest that we avoid making, and that is the following. People have either opted in or failed to opt out of the system, and thereby somehow implicitly agree to a unique identifier.
Even if that were the case, my suspicion is that if we went to a system of unique identifiers even for people in the NHIN, it would not be long before that system would migrate to everyone, even the people who wanted to be outside of the system.
So if we want to make some arguments as to whether we ought to have one. There are lots of good ones, accuracy being one, but I would suggest that we steer away from, well, it is only the people who have elected to be in the NHIN.
DR. STEUERLE: Just a trivial comment, which affects all groups I am working with these days. Are you planning on having a web-based version? People have referred several times in other documents that you refer people, it is enormously helpful if you have a web-based version that you could click for those other documents.
I think this has already come up twice or three times in here, about referring to --
MS. GREENBERG: You are talking about the final letter could have a hyperlink in it?
DR. STEUERLE: In several cases the issue has come up, where we have said something somewhere else, we don't want to put it in here. I think for a lot of readers it would be enormously helpful to have these hyperlinks.
MR. REYNOLDS: This is exactly the kind of input we want, so thank you. We will take all that in consideration as a subcommittee.
Number five, Margaret.
MS. AMATAYAKUL: Five, location of health information. Provide functionality that will locate where health information exists for identified individuals.
5.1. Utilize the unique organizational identifier such as national provider identifier, national plan identifier or other identifier, as may be assigned during the entity's certification process, to locate entities holding a specific individual's information.
5.2. Provide notification concerning location of information, pointers to the location or the data itself to the requester, depending on the structure of the network used and agreements in place.
5.3. Provide information back to the requester if identity, location information and/or data could not be determined and/or provided.
Observation. The NCVHS observes that there are a variety of ways that the location of health information may be identified, and that in some variations the provision of access or retrieval of health information is performed simultaneously with the location of the health information.
It further observes that some of the variations relate to whether the subject of the query is a specific individual's health information or other information. Other information may be de-identified and/or aggregated health information. A Nationwide Health Information Network may also serve to support the exchange of information not related to or derived from individual health information such as hospital census information or the availability of a clinical trial at a particular research institution.
Variations in location of information identified include, for services that exclusively indicate that information for an individual exists in an organization, but with no indication of the health information, or services that include information on what kinds of health information can be found at the organization. The above two variations could be accomplished through a centralized record locator service, a set of federated record locator services, or a process or a master person indices perform a person locator service.
Another option is, services that indicate where an individual's health information exists and support the retrieval of the information from the relevant source. This service may hold relevant information until all are collected and then transmit the collection in response to the query, or this service may negotiate the transmission of relevant information from one party to another without any transient storage.
Finally, services that retain summary data in a regional repository. Such summary data may be individually identified such as immunization registry, may be de-identified data such as information about adverse events associated with a particular medical product, or other information about the number of days in a particular hospital's emergency department.
Recommendation five. The NCVHS recommends that HHS should collaborate with public and private organizations in the development and deployment of services through the location of health information about individuals that would accommodate local preference and system capabilities to the extent feasible, yet be compatible within a Nationwide Health Information Network.
MR. REYNOLDS: This is one where obviously the devil is in the details as we get to it. You are getting a flavor here of the architectural variations. This is a prime example of how you get to a point where this can be done different ways.
MR. BLAIR: I am listening as Margaret takes us through each of these items. Those of us who have worked on the letter know it so well that we start to work on the definitions and the details and the specific words and all that. So I have been trying to listen from the standpoint of someone who might be new to this.
My thought was, behind this section we know the flow. We know the sequence. I am wondering, this is an open question, especially those where this document is new, would it be useful or helpful to either point out the process that we are going through that is behind the sequence here, either in a graphic or a picture or words, or as you read this through for the first time, did you understand that right away without an additional aid?
DR. COHN: Jeff, let me ask you a question. What I think I am hearing you say is, in one of our appendices we have information flows, and should we put a footnote here that indicates that for greater information refer to that appendix for the information. Is that what you are suggesting?
MR. BLAIR: Not exactly, no, not to refer somebody. I just didn't know. Maybe the silence is saying that people understand this section without having a picture of the flow before we step through it. I didn't hear anything and I didn't know what peoples' faces were like.
DR. STEINDEL: Harry, when I read this section for the first time, and given what I have been doing for the last couple of weeks that was in situations where Jeff could say we may not be reading it with the exact amount of clarity like a Barcelona airport or something like that.
My take-home message from this with respect to the recommendation was, I thought the text supported it very well in the sense that it was pointing out examples of the complexity of the process. I thought if we went any further in stating some examples that say there are multiple varieties, there are multiple complexities, that there was no way that we could be inclusive. Hence, it was best to stay at the level that we stayed at, the for example level, a couple of variations on those examples, and then give a very straightforward recommendation which is, look at it, let's investigate it, let's figure out what services we really need, which is really what the recommendation comes to. The text before it supported it very well.
DR. TANG: I think you did a very nice job wording it, particularly the last part, to the extent feasible yet be compatible with a Nationwide Health Information Network. I think that does a good job of outlining what the constraints are in a very tactical way.
Let me test that. So for example, and the scenarios you outlined above were very illustrative, let's say we decide that we should not reveal what kind of information was at a location. So if you do have health information at an oncology center, it is very revealing. If there were a national policy that says we won't reveal that in record locator services, then it would be true that you would promulgate that, and despite the variations in architectures, no one would be communicating that information or expecting to receive that information. Is that a consequence of your statement?
MR. REYNOLDS: Yes, if that is the standard and/or structure that is established that would be a fact. Does anybody disagree with that?
MR. BLAIR: Simon, I think I am hearing from the lack of response to the question I have offered that people do understand this section and don't need an additional aid.
DR. BICKFORD: This is Carol Bickford from the American Nurses Association. I have two comments. The first one is in relation to line 575 where we are talking about providing information back to the requester.
I raise the question, is there some sort of authority given to that requester to make the request, and you would provide the information back to them?
MR. REYNOLDS: Yes, and that was covered. That is in certification, authentication and the other areas that we covered earlier.
DR. BICKFORD: Do you wish to carry that same thought to authorize requester to this space, to assure that that continuity flows through this discussion?
MR. BLAIR: That almost gets back to exactly the point I was making. That was covered as part of the process, and you missed it. I am wondering if a picture would have helped you realize that that was the very first step in the process.
DR. BICKFORD: I wasn't here for that discussion, but the point is, I am going to be pulling this out. I am going to be taking a look at this content, not necessarily reading what went before. Is that authority an important piece that has to be included?
MR. REYNOLDS: It was discussed in the document.
MR. BLAIR: It was the first step in this section when we went through.
MR. REYNOLDS: The thing we may want to more clearly state, especially in the preface to each of these, is that once they are discussed they are inherent in the entire discussion. They are going to continue to be evident in each of the pieces, so you are doing a building block.
First you certify that they can be there, you authenticate who they are and on down before any of this stuff starts flowing around.
DR. VIGILANTE: This is very specific. I agree with the statement that this does form a hierarchical flow, so there is an implicit authorization. But actually, the way this is worded, provide information back to the requester if identify, location information and/or data could not be determined and/or provided. But one reason the data may not be able to be provided is that the requester is not authorized to get it. So it is inherent in the statement.
MR. REYNOLDS: Again, reminding people that we are building off of what we already said as we go through each step of this.
DR. WARREN: Gene had said earlier, it would be nice to have hyperlinks in the letter. If there were a hyperlink at that point that went back to the authorization, would that be helpful to you?
DR. BICKFORD: That would be very helpful.
MR. HOUSTON: Going back to the beginning of the letter, on page six around line 211, we talk about the fact that various systems would provide services to enable health information exchange in a secure and protected manner. Maybe somewhere in this section if you wanted to expand slightly on that concept of that hierarchy, it might be good in that area. It might already be assumed in some sense.
So I think we are probably doing a lot of what we are talking about doing already. If we want to refine the wording a little bit, it might help pull that out.
DR. BICKFORD: My second commend is in relation to line 613, where you are talking about the development and deployment of services. Is there an evaluation component included anywhere in this document? You are talking about collaborating with public and private organizations on the development and deployment of services. My question is, should it be and evaluation, so that continuing review is articulated, that that is not forgotten again.
MR. REYNOLDS: That's fine. I think it is the same message. We need to continue to make it clear that all these pieces work together, and it isn't going to work without one or two of the major pieces. They all have to be inherent as you are building along.
DR. STEINDEL: I think Carol raised a very good subtle point with that statement. How do we consider evaluation versus certification? Certification obviously is an evaluation, and if certification is done right it is ongoing and it changes all the time, but evaluation is another component of the same type of process and may not be as formal.
MR. REYNOLDS: I'm not understanding what you mean.
DR. STEINDEL: You're not understanding what I mean? In certification you usually have a testing criteria. You do this, you do this, you meet it, you do not meet it. If you pass a certain bar you are certified to do it. Your system has been certified to do this.
But if we are taking a look at like record locator services and we want to evaluate the efficacy of record locator services, we may enter into a less rigid research protocol which would provide us with the information to develop certification criteria.
So there is a subtle difference between the two of them that I don't know if we want to state in this document at some point or not. We might just want to make a note of it.
MR. REYNOLDS: We've taken the note, so we'll go from there.
PARTICIPANT: Only to build on that, I would only like the notes to reflect that in areas where we talk about testing, because there are several areas where we say you are going to try and test this, so I think the spirit of your comment goes to those sections as well.
DR. STEUERLE: I have certainly been in government offices that do a lot of evaluation, but they end up to be pretty random, depending upon what the latest pressure is. Is it clear that you are suggesting, without knowing what it would be, a systematic approach to evaluation of these various components, not just this one?
MR. REYNOLDS: I think that is very well stated. Yes. With CCHIP, with everything else that is out there, you would hope that as these criteria are identified it becomes part of these other processes.
DR. STEUERLE: Is that actually part of the recommendation, that there be a systematic approach to evaluation of these components? Not just that you evaluate, but that systematically somebody sits down and says what is our process; do we evaluate this periodically or do we do this every three years, do we make sure we get the certification but forgot the privacy? I am just asking.
MR. REYNOLDS: I would say yes, but again, I think it then caries over to everything that we are saying. Remember, these 15 items that we are dealing with here, every one of them has to be good as itself and a part of the whole, so we have got to make sure that as we go through each one of these. So your statement is almost an overarching statement of everything we are talking about.
DR. STEUERLE: The review part, too.
MR. REYNOLDS: Yes, a continuous review. So whichever of these are approved, whichever are implemented, whichever goes on, there needs to be a continuous ongoing review just like the other standards processes or anything else that keeps it current.
DR. STEINWACHS: It would help me to get a sense of -- there is a lot of concern about matching the wrong records together, we just talked about that, but not finding all the records or some of the records never getting into an electronic form.
What is the level of concern that -- and Steve was saying how good is the locator system, but that is also an issue. What is the nature of concern around that? There is nothing here that talks to quite the same concerns that we just went through when we say Simon's medical history may get attached to my name. Heaven help me, what kind of treatment I am going to get.
MR. BLAIR: If you are not able to make a match, and you have to go to manual processes or other backup pieces, it is a frustration, it is an irritation. It costs money, it costs time, but it doesn't cost a patient their life.
On the other hand, if you have a false positive match, where you are matching the wrong patient before a surgery, that is unacceptable. So false negatives are an irritation and a cost, but false positives threaten lives.
So when we were hearing testimony, the effort of folks that were working with statistics to try to evolve their matching patients to their records, they attempted to work both down as well as possible, but the false positives were considered unacceptable. They were trying to get back to zero.
DR. STEINWACHS: Just one last piece. I would generally agree with what Jeff is saying. There are times you might think of where not having the information can also cost you your life. So it may not be as threatening, but it is not consistently not threatening to not have the information.
PARTICIPANT: And not knowing that you don't have it.
DR. STEINWACHS: Yes, and you think you have got it. That is part of what the system does. It may give you more confidence that you have everything and you normally wouldn't.
MR. REYNOLDS: Great input. That is what we are looking for. Transport standards, Margaret.
MS. AMATAYAKUL: Number six, transport standards. Transport requests for location of information, requests for data, data itself and other types of messages such as notifications of the availability of new data, to destinations using general industry recognized transport types, example, Internet protocol version six, and authorized recipients specific mode, example, pre-fax versus transaction.
6.1. Support content, vocabulary and code sets and application protocols, message formats used for the exchange of health information within a Nationwide Health Information Network that conform to HITSP interoperability specifications.
6.2. Verify the integrity of data transmission.
6.3. Enable standard information meta data, for example, UML, XSC and/or HITSP specified, to be included in data retrieval or delivery of messages in order to convey sensitivity restrictions, individual permissions and editing preferences, and perhaps I should say et cetera based on my earlier comment. Support the ability to include an error message service that notifies the requester of authentication or authorization that is not verified.
6.5. Support the ability to hold and aggregate appropriate error messages or data based on an entity's query.
6.6. Support the ability to move or copy data as directed from one entity's system to another, such as from one personal health record to another personal health record, or from one provider system to a personal health record.
6.7. Provide the ability to send, receive, re-transmit acknowledgement of data requests or data content transmissions.
6.8. Enable entities and systems to update, correct and amend health information in accordance with HIPAA requirements and internal policies.
6.9. Insure that all parties involved in the physical transport of health information manage the connections with contingency plans, security incident procedures, ongoing evaluation and risk management, and retention of data and meta data, including audit logs, as required by state statutes and other requirements, for example, as may be provided by HITSP standards.
The observation is that NCVHS knows that it is important to recognize that many of the functions associated with transporting meaningful messages depend on the ability of an entity's systems to produce standard messages, or that the e entity will utilize one or more third parties to process messages into standard formats. Such conformance to standards may be enabled by a network service provider, system vendor, entity itself or other means. Such variation appears to be compatible with the goals of a Nationwide Health Information Network that is deployed in a federated manner.
Recommendation six. The NCVHS recommends that the HHS support the work of the Health Information Technology Standards Panel, HITSP, in promoting the creation and adoption and conformance to message and content standards for use within a Nationwide Health Information Network. See also recommendation 16 for specific standards gap.
MR. REYNOLDS: Comments? Okay, number seven.
DR. FITZMAURICE: A question or a suggestion. Under transport standards, line 619, it says transport requests for location of information. Would we also want to put in there, transport requests and their responses, closed parentheses?
MS. AMATAYAKUL: What line are you on again?
DR. FITZMAURICE: 617, transport of requests for information, and I would suggest transport requests and their responses or responses to the requests. If we are saying transport requests and we don't say transport responses -- if you think it is understood, that is okay.
MR. REYNOLDS: We will make a note and wordsmith it.
DR. FITZMAURICE: It is a wordsmithing.
MR. RODE: Just a comment on 6.8, line 629. You may be assuming this, but I'm not sure it is clear. The correction in one place transfers to corrections in other locations with that information. In other words, does the correction get transmitted in this network?
MR. REYNOLDS: Which line are you on?
MR. RODE: Line 649. We can update, correct and amend, but does that go through the system or is that in one location?
DR. FITZMAURICE: Dan, what you are asking is, there is an audit trail with these requests, and if you change the base information does it go past audit trails and re-correct all the information or notify the requesters that this information has changed?
MR. RODE: Yes.
DR. FITZMAURICE: I would suggest no, that is not what we are saying.
MR. REYNOLDS: I don't think we were saying that, were we?
DR. STEINDEL: I would actually say that we are silent on what we mean by how the correction flows through the system.
MR. REYNOLDS: And if.
DR. STEINDEL: And if. We are just saying that corrections should flow through the system, but how it flows through the system or where it flows through the system, in this letter we are silent. I think at this stage of the game, we really have to be silent, because this is an extremely complex area. It is undergoing a lot of discussion.
MR. REYNOLDS: Yes, because each entity would have to keep track of everybody that asked anything, and then if anything changes would have to resend all that stuff out saying something changed. The whole push versus pull discussion that we have in here also drives that. So I would agree with you. But Dan, thanks for the comment.
Number seven, Margaret.
MS. AMATAYAKUL: Number seven, data transactions. Provide functionality that will enable data transactions to occur among authorized entities and/or users upon specific trigger events, such as to automatically send final lab results for any previously sent, preliminary results and any changes in medications prescribed, report medication errors, notify public health about the occurrence of a biohazard event, inform individuals about the availability of a clinical trial, determine a hospital census for disaster planning, et cetera.
7.1. Identify the source of any externally provided data.
7.2. Enable data filtering to allow for subscription and unsubscription to specified or all available future clinical events data.
7.3. Enable entities to acquire data to monitor a previously detected event, generate alerts, notifications or perform similar functions.
7.4. Enable entities to account for disclosures in accordance with HIPAA requirements if covered entity, or provide an audit trail of accesses and disclosures if not a covered entity.
Observations. The NCVHS heard testimony from some that a Nationwide Health Information Network should only enable retrieval of data based on a specific query pull. Other testifiers however supported the ability to offer publication and subscription services that enable with permission the ability to inform others of the availability of new or updated data publication and the ability to be notified when certain data become available, subscription.
Recommendation seven. The NCVHS recommends that HHS support a Nationwide Health Information Network initiative within which both pull and push data transaction services can be compatible based on local or community policies.
MR. REYNOLDS: Comments.
DR. DEERING: This may be just editorial, but in the recommendation itself we were recommending that they can be compatible. Is that the word we mean, or do we mean supported or accommodated? We are not specifying that they are compatible; we are saying that we would like them both supported within the NHIN, if I understand correctly.
MR. REYNOLDS: I think that's fine.
DR. TANG: This recommendation like all the previous ones reminds me of Mike Fitzmaurice's comment. I am wondering then, does that mean we should have a more explicit way of discussing how you balance the need for standardization versus local preferences. Although I just phrased the wording of one of the earlier versions that allows for both, probably it needs to be more explicit so it doesn't come across that we should accommodate all local practices.
That actually won't work. So we have to be sensitive to local needs. Perhaps a paragraph that just puts that out there explicitly will be helpful to the overall discussion.
MR. REYNOLDS: I think if I am not mistaken, what this is saying is, we talked how the data might be available like for research and other things. If a local community, let's say a RIO, you have got those different entities that sit up there to see how it might work, if they had a clinical trials registry and they decided they wanted that data to be there, it could be incorporated.
It may all be done in a single way, a standard bit of information and a standard flow and a standard other thing, not necessarily that they get to pick the way they would do it. I may not be explaining it well.
DR. FITZMAURICE: I am a little bit puzzled, because a lot of these appear to be applications, things that would be handled within the edge. If I want something sent to me, I will tell the laboratory, send me the final results, and they will send it as a normal NHIN transaction.
I'm trying to think, is there anything that the NHIN would have that would prohibit these kinds of example transactions that I want to make sure the NHIN has? So I am puzzled that this is very application specific and maybe within edge or edge to edge -- is there anything that we have to make sure the edge does or doesn't do so that these might be prohibited? I can't think of much. Maybe it is my not being able to see, would the NHIN if it doesn't have this could stop this, these wouldn't flow. But it is an e-mail. Send me an e-mail with the latest lab results. I get the e-mail and the NHIN doesn't know that that is a function being accomplished from my edge to its edge.
MR. BLAIR: That's a very good point.
DR. FITZMAURICE: So maybe our general statement is that there are some services that are performed by the edges, and we should just be aware that we don't want anything in the NHIN to prohibit useful services. That doesn't say that very well, but I am having a hard time seeing how this applies to the NHIN and not just to the applications themselves.
DR. STEINDEL: I see where Mike is coming from. I also had some thoughts about it when I read through this and everything. But again, when we got to the recommendation part, the way I read it, and I have been thinking about Mary Jo's comment about, is compatible the word we mean. I'm not sure we want that or another word.
But this gets to some of what Mike is speaking about, this idea that the NHIN should support push-pull data transmissions. That is basically what this recommendation says, that we shouldn't block the use of push-pull data transmission techniques.
But we also should be aware of is that there may be things that are down at the local level that will block those push-pull transmissions, like for instance if we consider a local community, a mental health network, a private mental health network. We say that we subscribe to the services a private mental health network. That is our certification on the NHIN. That blocks certain types of transmission.
What we are saying with this is that the NHIN should not prevent an organization from blocking those transmissions. I think that is what it says.
DR. FITZMAURICE: That if it wants to block it, it will do it itself?
DR. STEINDEL: It can do it itself and it should be allowed, but the transmission comes in and it can say no, I am refusing this transmission.
MR. REYNOLDS: Let me make one other point, Michael, that I think is key as we try to look at this. You said the NHIN. I know what you mean, but it has been the linchpin of the entire ability to create this vision. It is a system of systems. If it was sitting in the middle of that room, we would write a different document.
DR. FITZMAURICE: I'm not sure that we would, because I think of a system of systems as an entity. So there are things that govern the whole system, even if the components have to follow those rules.
MR. REYNOLDS: I agree, but I am continuing to adjudicate, there is no the NHIN. We have to talk about a set of functions and a set of capabilities. Push versus pull is a set of capabilities. It may be between two entities, it may go through some kind of a central place, it may go through six entities.
So what you just said to get done may traverse six entities to actually occur, and the push versus pull philosophy still needs to be kept intact and all the other things related in here need to be kept intact. That is the struggle that we have got to be sure we continue to maintain to protect.
DR. FITZMAURICE: I've got another question. How is a system supposed to know whether something is push or pull? If I can an e-mail that has data that I want in it, that is great. If it asks me a question, that's great. But how does the system know which is which?
MR. REYNOLDS: I can give you a quick answer. These are the kind of things that go on between entities right now in many different ways. It is because they have business relationships.
We have clearly steered away from putting business logic in the middle of something called an NHIN. There is going to be a lot of business logic between entities, transported, data standards, data formats, everything else. We are trying to stay away from building a set of business logic in some center ground that decides how everything does or doesn't occur.
DR. FITZMAURICE: I may readily agree that inventorying my inventory to see if I have something in there, or you may push information to me that says you have got this in your inventory, so I can add my inventory to yours. But I don't know that the NHIN needs to know if it is push or pull for that to work.
MR. REYNOLDS: We are talking about a functionality. We are not talking about the NHIN doing it.
DR. FITZMAURICE: I guess we are talking about the negative, that the NHIN should not prohibit that functionality, even if I can't think of anything that would prohibit it right now.
DR. LOONSK: I think I have a comment to make that supports Paul's suggestion that there may need to be a tension here between the variation in regions and capabilities with a need for this all to work together.
It is not clear to me that we have completely explored the implications of data flow for all push permutations, and whether indeed we could say at this time that there is no need for shared functionality in this regard. Said another way, I think we have to leave the door open for this all to work together. There may be a need for some common approaches to accepting push or accepting pull. So that tension may be something that still needs to be there.
Certainly from the prototype standpoint, we still see that being worked through. So like the previous recommendation which expressed the tension between local variation and the need for commonality, I think that this one may need to manifest that as well.
A subpoint on that is that the published scribe which is referenced in this area is a particular technical approach to push. I think that the different technical approaches to push are still being investigated, and it is not clear that it is forcing that architectural approach. It is one of the variations that is being considered here in a push methodology, but it is not the only one.
MR. REYNOLDS: Simon, for purposes of making sure that we stay within our time, number eight is auditing and logging, which are pretty inherent. I would recommend that maybe the committee take a look at this and make any wordsmithing to this, but auditing and logging is a pretty basic premise in anything these days, and we need auditing and logging. So I'm not sure that reading all the words and going through it at this time, I'm not sure that it is a subject that would need it, but I'll defer to you as the Chair.
Does anybody have any concern about not going through this in detail? You have the document. We would love to hear your input. But for purposes of continuing forward, I'm not sure -- all right, let's go to number nine, Margaret.
MS. AMATAYAKUL: Nine is dynamic data access, provides a dynamic data access, direct response request interactions, the specific target systems, for example, query of immunization registry, within a Nationwide Health Information Network.
9.1. Support consistent methodology for granting emergency access.
The observation is, the ability to query and obtain a response in real time at the point of care or to respond to a disaster situation is an essential function of a Nationwide Health Information Network that will improve patient care, enhance emergency responsiveness and reduce medical errors. Access to health information in an emergency situation however must be performed within stringent security controls that enable access only when legitimately required and afford special non-entering of those accesses.
Recommendation nine is, the NCVHS recommends that HHS support the capability of a Nationwide Health Information Network that enables dynamic data access within a construct that affords emergency security measures.
We did have a question whether we should separate this out or incorporate into number six.
MR. BLAIR: Number six was?
MS. AMATAYAKUL: Number six is transport standard.
DR. COHN: I think that rather than spend the committee's time determining whether it needs to be reorganized, I would have us look at whether or not we agree with the recommendation.
MR. REYNOLDS: The other thing is, you were harkening back to Sue's comments earlier, about them building the rules about these kind of things. One of the things that I would like to have us take a look at is whether or not we will want to reference that at all in this, because they are already -- she announced this morning, they are already identifying those rules for emergencies, as to privacy and whether people could get the records and everything. She testified this morning, so whether or not that would need to be noted here, since it is already a work that is in process the same way.
Any other comments from anybody else?
DR. FITZMAURICE: It is the word dynamic. I tend to think of dynamic as real time. But maybe you mean immediate, in the case of a national disaster. You mean break through all the firewalls, we have an emergency so it is an immediate access. Whereas, dynamic doesn't connote immediate to me. It means it changes, it varies.
DR. TANG: I thought most of these queries were dynamic or real time. I hope I haven't been completely in the dark.
MR. REYNOLDS: No, you are correct.
DR. TANG: I think your issue you are addressing is the emergency access which may cause some exceptions to be invoked with regard to authentication or authorization or changes in authorization, rather than just being truly dynamic and interactive.
DR. COHN: I think we are talking about emergency data access. I don't think this is timely data access.
MR. REYNOLDS: Any other comments on number nine?
DR. FITZMAURICE: What did we decide?
MR. REYNOLDS: Emergency. Use the same words we used in the body. Number ten.
MS. AMATAYAKUL: Number ten is meaningful communications. Enable entities or services engaged by entities to support meaningful communications for users.
10.1. Provide for mapping between versions of a standard in multiple standards, mapping terminologies and code sets and supporting Americans with Disabilities Act Section 508 compliance.
10.2. Support display, entry and retrieval of data in multiple ways as determined by the needs of the recipient.
Observation. The NCVHS believes that for the exchange of health information to be meaningful, the health information must conform to industry recognized standards. Such functionality may be performed or incentivized in a variety of ways. Networking services do not include significant data mappings or translations beyond different versions of accepted standards, or networking services include significant data mappings and translations specific to health care entity, or networking services business model includes fees for supporting mappings and translations.
Recommendation ten is, the NCVHS recommends that HHS support the continued development and testing of approaches for a Nationwide Health Information Network that demonstrate that these mapping and translation functions performed by network service providers or other entities may be appropriate in environments where applicable agreements exist.
MR. REYNOLDS: Comments?
DR. STEINDEL: Harry, I have a question concerning 10.2. We say support display, entry and retrieval of data in multiple ways as determined by the needs of the recipient. When we get into display and entry, we are now talking about user interface specifications, which I think is outside the scope of the NHIN. That is something that is a system level requirement.
It is a very touchy area to get into, and it is one of the things that has bogged down a lot of the work of NCVHS in deploying a system.
MR. BLAIR: With that, it didn't say perform it. It said support the enabling of it. Is your statement still true even though it has support the enabling, but not the performing?
DR. STEINDEL: Actually, nothing else in this whole statement on ten including the recommendation makes any mention of user interface type services. It is just that little comment in 10.2.
MR. REYNOLDS: Is 10.2 really talking about services that are to be allowed rather than defining what has actually gone in those services? If you read this, it almost starts reading like a clearinghouse clause, a little bit. This is saying these are the services that might be performed by such entities or RIOs or anyone else, and that we are recommending that they not be precluded.
Margaret?
MS. AMATAYAKUL: I can just tell you the source of this. There was a thumbshell category called data rendering. It came out of that section on functionality.
MR. REYNOLDS: So it was one of the 977 functions that was necessary.
MR. BLAIR: Maybe I am almost going back to what I think you were about to say, Harry, where you were doing the corollary of this statement, which was that the NHIN should not preclude presentation in various forms.
If we state it as the corollary, then I would ask Stephen, would that be okay or not?
DR. STEINDEL: Jeff, can you run that one more time?
MR. BLAIR: All right. I guess this gets down to IT areas, which are even beyond my capability.
This originally said that it would enable and support presenting information in different formats. You wound up saying quite correctly that if it was implying that it was going to perform that capability or an end system type capability. All I was saying was that if we took the corollary, that it wouldn't do anything to mitigate or interfere or prevent that. Do you still feel uncomfortable with us making a statement like that?
DR. STEINDEL: No, that I have no discomfort with. I think we can make it. One reason I am sensitive to this is because in some other groups I work with, I work closely with NHS. One of their problems right now is, a lot of the deployed systems are limited in the field lengths that they can display. So when you try to do something like SNOMED, which might have a 256-character text, and you have a ten-character field length, you have a little bit of a problem.
MR. REYNOLDS: Margaret has fixed it. The NHIN should not preclude. Any other comments?
DR. CARR: Could you give an example of what this is? I know a lot of people understand this, but it is a little bit technical. To Jeff's point, for the lay reader this is confusing. So you could just say a little bit more about what this is?
MR. REYNOLDS: I'll try. You may have a single doctor office that wants to be part of the NHIN and do certain things, but neither has the wherewithal, the money or the ability to connect. They may have their RIO do some of these things, where they may connect directly into a RIO, not have their own system, not have their own information, connect into a RIO and have some of these requests and other things done through there. So the RIO would handling possibly the data entry, possibly handling some of this.
Our whole issue with this whole thing is, there are going to be many, many kinds of relationships, many, many kinds of entities that are going to be out there. We are just trying to preclude not being so prescriptive in here that you eliminate people being able to group up in ways that may not be totally clear now, and function accordingly.
If anybody has a better example or better explanation, please jump in right now.
MS. AMATAYAKUL: I can just go back to the original. Some of the examples that were included were for example a different language, like English to Spanish translation, or table versus graphic.
DR. CARR: I found it very difficult to understand. So working services not include significant data mappings or translations beyond versions of accepted standards. So you are saying -- what are you saying here? Network services do include versions of accepted standards? I don't know. Maybe it is just me and I don't understand.
MR. REYNOLDS: Let John comment.
DR. LOONSK: I wanted to follow up on the previous discussion around 10.2. I do think that the statement that is now up on the board is a different statement than the one that was first put forward, I want to make that point.
I would encourage ongoing surveillance for using the term NHIN as doing something along the lines of what Harry had suggested before, and suggest that wherever possible we do discourage that because of the difficulties of this conversation about what the NHIN is and what it is not.
I will note that the models being considered for health information network service providers at times do include direct access. So not be an NHIN, but health information network service providers very well may have models where they provide direct access.
I also would point out that some of the discussion of the consortium in this regard also supported administrative functionality, where there are needs regardless of the model for direct access for management of access of entities to systems, et cetera. So all those things are relevant in this case.
MR. REYNOLDS: Margaret, did you have further comment?
DR. STEINDEL: John, what do you mean by direct access? Direct access by the service provider directly into the client system?
DR. LOONSK: I'm sorry if it wasn't clear. There are models where the health information network service provider may provide interface screens for access by users of the system, in which case some of these considerations would then be more direct.
DR. STEINDEL: Thank you for the clarification.
MR. REYNOLDS: Clear definition of entities is very unclear, right, John? How people are going to group up and what services are going to be offered needs to be left flexible.
Margaret, did you have a further comment?
MS. AMATAYAKUL: I was just going to address the three bullets starting on 749. I think that was your question.
DR. CARR: I am trying to understand what is being incentivized. I understand the part until we get to the observation. Then it says, such functionality may be performed or incentivized in these three ways. So those networking services do not include significant --
DR. LOONSK: It is confusing. It is a complicated area. There is a model. There are several factors involved here. One is rates of adoption, progression to a more standardized approach for some of this. Another is the business model for some of the health information network service providers, wherein it may very well be that while a data target needs to be expressed, that different hospitals and other entities who participate, even if they don't quite meet that target, and potentially pay more because of their variance from that standard.
It is one of the models for business support of these health information network service providers that is very much on the table. The benefits of it are that potentially it helps spur adoption. Not everyone has to have the same exact standard manifest immediately to participate, but that the health information network service providers could help with some of the data transformations and mappings to get them there. But you still need to have the target.
So those concepts are manifest in that text. That is part of the complexity.
DR. COHN: I don't want to wordsmith this one right now. I am thinking that our original language might actually be the right language based on the conversation.
The other piece relates to the conversation that just immediately occurred. I think the sentence that introduces the three bullets is confusing. That brings up the question. It isn't so much what is in the bullet. What we are talking about is architectural variation again, except it is being re-introduced in a way that doesn't bring it out in that fashion. So I think that would be something that we need to note and wordsmith.
MR. REYNOLDS: So noted.
DR. TANG: Just one suggestion on the naming of this section. As you described at the opening, this document is intended for those who have been working in it for a long time and those who haven't. If we label this meaningful communication, it might by reduction say that all the others weren't. So another possibility is to label this as interoperable communicating.
MR. REYNOLDS: Thank you for -- we think it was a positive submission. Moving on to number 11.
MS. AMATAYAKUL: Number 11 is data repository. Enable the use of a data repository to permanently store data which entities have contributed in accordance with a specific data set, for example, tumor registry, or for other purposes in accordance with agreed-upon policies.
Observation. The NCVHS observes that many data repositories exist today in support of health care quality, patient safety, biosurveillance, research and other legitimate purposes.
Recommendation 11: NCVHS recommends that HHS support the continued development and testing of prototypes for a Nationwide Health Information Network to test the minimum but inclusive functional requirements for a Nationwide Health Information Network against multiple scenarios, including those where there may be data repositories established by policy.
DR. DEERING: It seemed to me that the first three quarters of this regulation are general. In fact, jumping ahead of 15.2, we have as a next step that we recommend that they test against multiple use cases and scenarios. Then it is only the clause including too that is specific to the section. I think we had consciously tried to make our recommendations map.
So just as a suggestion, since we have already covered the first three quarters of that elsewhere, we might want to wordsmith it down to be more precise to the section.
MR. REYNOLDS: What, the recommendation you're talking about?
DR. DEERING: Yes.
MR. REYNOLDS: Okay. Any other comments?
DR. CARR: I don't understand some of these things. We have data repositories in some settings. So this is saying that we have data repositories, and the recommendation is that -- what does this mean, this recommendation?
DR. STEINDEL: Justine, I have the same question.
DR. FITZMAURICE: It would seem to mean, don't exclude those prototypes that have data repositories.
DR. STEINDEL: What I don't understand, and let me phrase it this way, is why are we specifically spelling out data repositories as a specific example that should be keyed as some type of data storage entity? We have already said in this that there are data storage entities. Otherwise why would we need a record locator service?
Why can't we use a record locator service against something that is a data repository as well as a set of patient data? Data repositories are very specific use case examples, like tumor registries, but I think this is going to cause some concern in the data repository community, because they have very specific access requirements to their data, and they may not want to be accessible by the NHIN or participants in the NHIN.
So I think we have a red flag here.
MR. REYNOLDS: Another side of that is whether or not they would want to be able to use the services of the NHIN to capture that information. So you don't want them to also be precluded.
So there are two sides to that issue. One, they say they want to exist and they want to be what they are, and two, we are talking about building a nationwide health information that may get them their data in a better and different way. So I wouldn't be as quick to throw it away as you appear to be.
DR. STEINDEL: But Harry, the way I read this recommendation is, it concerns the storage of the data and not the acquisition of the data. I think we want to rephrase it to the acquisition.
MR. REYNOLDS: I'm fine with that, but I wasn't ready to throw it away.
MR. BLAIR: Correct me if I have missed it and it is somewhere in here, but as I was listening to Margaret, it seemed the setup for this was to indicate that data repositories already exist out there. Then the recommendation basically said that they should continue to be used or grow.
I was left with the question of -- because I was expecting something to say what is the role of repositories related to the NHIN. In particular for example, would there be temporary repositories within the HIN or repositories to facilitate either aggregation of information for certain purposes or temporary storage of records for the purpose of facilitating a virtual health record? There are probably several other examples. I thought it was going to be leading to that. But I didn't hear a mention of that. Maybe we omitted mentioning these things for some reasons. Can you help me understand?
MR. REYNOLDS: Anybody got that?
DR. DEERING: I can't answer Jeff's specific question, which I think is probably a good one, but I think what I am hearing is not just that they exist and they are a good thing and we want to enable them. I agree with you, Harry, they have to be reflected here. So it seems to me that the question on the table is, are there enough unique things about them that they need to be pulled out here, or do we just need to make sure in our examples in our other functional requirements that we have peppered other sections of our text with just enough mention of repositories to make it clear that we intend them and recognize them as entities.
But the question on the table is, are there any unique needs that they would have. Is that where you were going, Jeff?
MR. BLAIR: Well, I guess I had an outstanding question even prior to this point. Are we going to discuss how we should approach aggregation of data when a record locator service identifies patient records?
In some models we aggregate that data to create a virtual record to be able to present that to an end user. I thought this would be the place where we would discuss that that either was enabled or not prevented as a viable model, or other things in terms of aggregation of data and maybe de-identifying data for public health research or clinical research or possibly bioterrorism use or something like that.
So there is a whole host of things where I thought that the NHIN would either have to create repositories, permanent or temporary ones, and that is not in the discussion here. So it left me empty.
MR. REYNOLDS: Carol, is your comment on what Jeff is saying?
DR. BICKFORD: It is in answer to this question, yes.
MR. REYNOLDS: We'll add that then.
DR. BICKFORD: When I was taking a look at this, I focused on the word permanently. Is the question you are really addressing, that retention for some specified period in perpetuity, like permanence or transience, is that what you are trying to get at as the concept? In which case there can be multiple venues for that storage and data repository might be just one solution, which is the limiting technology at this moment.
But is the question really permanence, and what constitutes that content, and for how long is permanence? Is it 21 years when you are dealing with a pediatric patient? Is it 100 years when you are dealing with the genomics, or 200 years? Is that the question? I haven't seen any recommendations in relation to permanence.
MR. BLAIR: Those are valid issues.
DR. DEERING: And I am just aching to add another wrinkle to it. We are talking about data here, but some of these repositories are tissue, they are not actually data. Now, certainly there is meta data about the tissue which is very important, but it is actually access to the tissue samples themselves which is of interest in the research function, not the information. It has nothing to do with patient health data.
So it is just occurring to me that maybe this is a far more complex area than we thought. I really welcome Jeff's emphasis, too. Is this where we also handle just the general issue of aggregation?
DR. LOONSK: Notwithstanding the issue of tissue banks, which I think are not within the immediate scope of the service providers, I think that these requirements were generated specifically from secondary use issues, and that this is oriented to secondary use. It is not about architectural variations in regional or health information network service providers, whether they need to store summary data or not. The latter being two architectures that are still being explored. In other words, can everything be retrieved as it is needed, or is there a need to have some repository in that regard.
That is an architectural variation that has been noted and is not the point of this. This is developed from the secondary use needs. For me, some of that comes out in the enabling language here, that there is a need to enable some of those secondary uses.
DR. BICKFORD: In light of this discussion, I also focused on data. Do we have a mechanism to maintain the knowledge within infrastructure, for example, the prompts and alerts? Is that part of this consideration as well? Or is it strictly data without any knowledge associated?
DR. LOONSK: There are certainly a number of activities going on in support of clinical decision support. Many of those relate more to EHR implementation. There are also identified needs for sharing that information. Potentially the NHIN could be one method of distribution, but some of that also is publicly available and does not have the same sensitivity of distribution as other data. So I'm not sure it has to be explicitly manifest here.
MS. AMATAYAKUL: I was just going to comment on Jeff's concern. We do have -- and I can't find it right away quick without doing a search, but we do have a statement that is, support the ability to hold and aggregate appropriate error messages or data based on an entity's query. So it does enable you to collect a bunch of data from multiple sources, but not send that data until you have it all together.
DR. STEINDEL: Margaret, it starts at 598, because I was looking for the exact same phrases.
MR. BLAIR: That is in this particular item?
DR. STEINDEL: No, it is under the section, location of health information. So that allowed the holding and aggregation of health information until all aspects of the query were completed.
MR. BLAIR: Interesting. Why do we have it there instead of -- I certainly was looking for it here in the data repository piece. If we decide that we want to keep it in this other location, I certainly would look for a pointer back to that sentence or phrase at a minimum, if not moving that phrase to this section.
MR. REYNOLDS: I think we have identified a section that the committee would have the opportunity -- I'm glad you found one. So we will take your basic comment, we need to build on that, too.
DR. LOONSK: I just wanted to nail down that there are at least there different issues here. The third that I think was just being touched on is some of the complexity from a medical legal standpoint of clinical information access and issues that relate to what was known and when was it known in an information retrieval in the context of providing care.
It is an exceedingly complicated issue relative to some aspects of what any medical record is, and how the electronic technologies either alter that or eventually support that. That is an issue that is still being worked in a number of different settings.
So three issues. One is the architectural variations of health information network service providers, whether they need to have some sort of store of data to support their purposes. A second is secondary use issues in enabling data repositories for secondary use. A third is this issue of whether, particularly in the context of a query or additional data on a patient, those data that were retrieved need to be recorded in some context at that retrieving site to sustain the knowledge of what was known at the time of that care provision.
DR. COHN: I think we need to wrap this up.
MR. BLAIR: I think we ought to go back to Justine and ask her if this discussion helped answer her question.
DR. CARR: Thank you, Jeff. Yes, and I appreciate John Loonsk's comment, because I read this as a much, much bigger story than the six lines that we have. So I think it would be helpful when it is evaluated offline.
DR. COHN: This is why we go through the documents in a public forum like this and review them with the committee. This one is going to require some more work.
Now, let me discuss about the next little while, how we spend our time. We have now been meeting for two hours, or close to it. We have a presenter, and I am very happy that he is here, who will start at three o'clock. We also have to go at least briefly through a letter that we will either have action on today or tomorrow.
Now, given that we have been going almost two hours, I am going to suggest that we take a break rather than trying to run right through to four o'clock. Let's give everybody a break. We will ask Dr. Halamka to join us, and we will hear about the HITSP. Then before we break for the day, let's go through the letter at that point, if everybody is okay with that. This is an action item.
MR. HOUSTON: Can I make a suggestion here?
DR. COHN: Sure.
MR. HOUSTON: There are two committees meeting this afternoon at four o'clock. One is Populations, the other one is the ad hoc work group on NHIN.
I don't know what Populations are doing, but we have two hours set aside for the ad hoc work group. Everything we are talking about right now and been going through for the last two hours is what this work group needs to get out the door. It doesn't make any sense in and of itself to have a meeting of the ad hoc work group other than to continue on doing this.
Is there any way that we as a group can stay together for some period after four o'clock to work through and get this done? Just a suggestion.
DR. COHN: Without trying to solve that problem, let's give everybody a break, and Don and I will discuss that during the break.
(Brief recess.)
DR. COHN: Can everyone please be seated? I do want to announce, and I will announce again later on, that the population breakout is apparently moving to 341F. I will announce that when we are ready to break up also.
With that, I want to thank John Halamka for coming and joining us. John is chair of the Health Information Technology Standards Panel. We were talking during the break and reminiscing about life in the sausage factory. The fact is that standards making is a -- I know that you are not responsible for making standards, but implementation specifications and identifying and recommending them is not an easy task, and we are very delighted that you have taken this on as a responsibility and are meeting with us today. So thank you.
Agenda Item: Update on Health Information Technology Standards Panel
DR. HALAMKA: The good news is that the interoperability specifications that were placed on the HITSP website today have a virtual 100 percent overlap with the chi standards you folks worked so hard on in 2000 to 2004. They have a higher degree of specificity, as you will see. We have really constrained those standards so that they are unambiguous. As a vendor or other stakeholder needs to implement software or communication, shall I choose HL7.24, 25, 26, 27? No, it is HL7.25, and here is what you are going to do.
But when you look at the chi standards, where you set HL7.24 and above, NCPDP, X12, HIPAA standards, federal medication terminology, et cetera, you will see those all very well represented in the work products that I am going to show you today. So you can pat yourselves on the back that we did start with and leverage everything that you had worked so hard on in the past.
What I would like to start with is just an overview of the process, tell you a little about how we actually got to this point, show you what we have done, and then what are we doing in the next ten days to finish this up.
Now, recognize that we really will never be done. This is full employment for all the volunteers. We have had an incredible process. Obviously this was all started initially with your input, David Braylor's input, the folks at AHIC. Today, HITSP is 206 different member organizations representing 17 SDOs, 162 non-standards development organizations, 18 government bodies and ten consumer groups.
We felt very passionate about having patient advocates involved, so I tell folks, what is HITSP, it is everybody from the AARP to the ACLU, and really, every stakeholder you can imagine, from payors, providers, employers, vendors, government entities. It is a very good opportunity to get input from all stakeholders.
In creating this process, we have set forward a number of steps. I will go through those in some detail, but at the moment, September 29 is our deliverable deadline. We have been focusing on wrapping up these things called interoperability specifications, which are these unambiguous cookbooks describing to a stakeholder how to describe information around the specific use cases that AHIC has given us, consumer empowerment, biosurveillance and EHR interoperability, though that is focused more on lab than anything else at the moment.
The organizational structure is that it will report in to the Office of the National Coordinator and to AHIC. I serve as a non-voting chair, so keep that in mind. I am involved in the weeds at every meeting, but I never have an opinion. And of course, that has been a fascinating position to take because I never take sides. I equally recognize the value of ASTM, IHE, HL7, every other stakeholder, and therefore become their advocate for whatever their point of view is without siding truly with anyone.
We have a project management team that has been extraordinarily responsive, and these folks work very, very long hours, I will tell you. This has been a 22-hour a day activity for the last six months. All told, 12,000 volunteer hours have gone into the interoperability specifications that we put on the web today, so really a quite substantial effort.
We broke our original process into the, let us get a harmonization request, let's insure there is good process with a board that has oversight at that process, but technical committees that do the actual work. Take those experts who really understand the nature of how standards may be commingled, standards maturity, standards applicability for a given purpose, and allow them to take those very specific use cases with events, actors and actions, and attempt to select standards.
When I first suggested, we will form some committees and it will all be volunteer, and you have to spend days at a time in Chicago, and you won't see your family probably until October, I expected five, six folks to volunteer. As you can see, 83 individuals volunteered for biosurveillance, 79 for consumer empowerment and 98 for electronic health record interoperability. So an amazing number of stakeholders have participated.
You can see the diversity of the co-chairs. We have had folks from industry, from academia, from the vendor community, from folks such as the Department of Veterans Affairs in government. So there hasn't been hegemony of any particular point of view or organization in any of this. In fact, some of these co-chairs have even stopped voting on individual interoperability specifications for fear that their leadership would be seen as biased. So again, I think people have been very sensitive to the nature of all inclusiveness.
What did we do? Around March 1 we received a set of initial use cases that describe how consumer empowerment might be used to exchange demographics and medications, eliminate the clipboard use case. When you go to the doctor's office, you will never again be handed a clipboard, asking your mother's maiden name, your basic insurance information, your medications, how we would insure public health entities would receive via push or pull, we will talk about these kinds of architectures, information in a de-identified or pseudo de-identified way that would empower public health surveillance, and how is it that individuals who have laboratory results that a Quest or a Labcore or a hospital or doctor's office would insure doesn't have to be completed because no one can transact them across the street.
Those use cases were translated into a very complex set of actions, actors and events. If the actor is doctor and the event is want to query, then what happens? All of these hundreds of actors, actions and events got down to the level of having individual standards placed against them. So harmonization requests, use case and requirements analysis, identification of candidate standards.
Just for those three use cases there were 700 candidate standards. I didn't even know there were 700 standards. But when you get to the point of saying not only do we have to constrain the message, but the vocabulary within the message and the transport of the message and the auditing of the message, and role-based access control, suddenly we are getting into ISO standards that people may not be that familiar with. You all know HTTP and you probably all know HL7, but do you know ISO 15000? This is the level of granularity that we have had to get to with identifying candidate standards.
But yet, there are still gaps. So where there is a gap, we push back the standards development organizations in this use case. Whether it is an architectural gap or a terminology gap, this is something that you need to work on. Those gaps, there are a few that are left in the interoperability specifications, but those have been assigned to the HL7, the ASTMs, the folks at the W3C, other organizations that were deemed appropriate for filling such gaps.
As well there are overlaps. This is where it gets very touchy. I'll give you an example of an overlap. If the folks in the payor community say, X12 is the way that we transact business, we do benefits eligibility, referral authorization and claims. We also have this thing called a claims attachment, the 275 transaction. I think all labs in the country should just use X12 275 because we the payors, we see the whole world in terms of X12.
Now you have got folks in the pharmacy world who have NCPDP transactions and have controlled vocabularies like NBC codes. So let's use the NBC vocabulary for everything. The pharmacies will love it. Then there are these folks who are involved in the FDA, who use a whole set of terminologies that are specific to FDA tracking and lot numbers and drug approval. Are we just going to deny the FDA exists? We can't do that exactly.
So suddenly, what we find, depending on the context, there are different overlapping terminologies and transport standards that are very well instantiated in various actors, be it the federal government, pharmacies, payors, small doctor's offices, et cetera, and we have to do one of a couple of things. We either say harmonization means unification, sorry, you only get one choice, it is either NBC or RxNorm or federal medication terminologies, just one, or we say we can't quite do that yet. Harmonization can't mean unity. Maybe it means instead of ten there are three, or maybe it means today there are three, but in 2010 we can get to one, and there will be a process for us to get to a reduced number.
So that is what harmonization was really all about, reducing 700 standards to a more manageable number. The way this went is, we started with 700 in March, we were down to 90 by May, and as of today we are down to about 20. So you will see that we have made substantial progress. We have said yes, NCPDP has a role, X12 has a role, recognize that there does need to be mapping between certain existing standards and a final harmonized standard, because it is not a green field out there. Over time we will get to less than 20, but for now, we think 20 -- and I use this word and some people don't know what it means -- is parsimony, the smallest number of standards you can get to that is rational. It doesn't always mean unity; it means the smallest rational number.
After doing that standards selection, and I'll show you the process we used that was quite objective, we then had to construct interoperability specifications. What is an interoperability specification? It is enough detail of methodologies for communication, not necessarily architecture, that would enable a vendor of a product to in an unambiguous way create an interoperable product.
The challenge is, it is a little bit hard to do this in a total absence of architecture. Is it going to be push, is it going to be pull, is it going to be request response, is it going to be publish, subscribe? At least in some general fashion you have to come up with an architectural statement, but do we say we are going to stipulate the nature of the language, the nature of the server, the kind of software end user application you create? We didn't get to that point, nor should we. So I think we have left enough architectural flexibility so the NHIN contractors and the vendor community feel reasonable about that.
Then once we created an interoperability specification, we then had to do a sanity check. We insured that there were 50 different stakeholder groups, a lot in the vendor community, going through these interoperability specifications to say do they hang together, could I read them, are they organized well, is the language and terminology similar across all of them and within sections? Is it specific enough, constrained enough for me to do my work? Have you selected the standards that are so unheard of and so untried and so immature that they can't possible work? We asked all those questions.
Then finally, on September 29 we release these in their final form, recognizing that we do have a very important panel vote coming up next Wednesday that will ratify this work.
How do we go through the selection of standards and the winnowing down of 700? By the way, I should say that the presentation that I have is slightly different than the one that we sent ahead of time. We had a board meeting on Friday. This is all getting done at such a compressed time frame. I am bringing you the up to the moment information. And I have left the PowerPoint presentation on this computer where it can be broadly circulated.
The way that we had to winnow standards was to get beyond emotion. The challenge in the standards development community, I have spent my whole life working on this particular standard. If I then talk to such an individual and say, would you think your standard is appropriate for this very specific context or use case, they would say no, I didn't create the standard for that, but my standard is still very good.
Fine, that is true. We are not picking winners and losers here. What we are picking for each use case, for each event in a use case is, what is the most appropriate standard that is constrained by that context. Suddenly if it becomes that objective and that quantitative, the emotion starts to melt away.
So we have very high level standard criteria which we say, is it suitable for the purpose, would you use an insurance company standard to transact clinical data. Maybe that is not the best way to do it. What about the organization and process to create the standard? Was it two guys in a garage, and we have never heard of them, and they created a standard and it is really cool? Or was it an open transparent process, well documented, that allowed much stakeholder input, public input, review, et cetera?
What about the cost? Is it a million dollars a copy to use the standard or is it an open transparent public standard? This isn't to say that costs are an impediment. We know that with SNOMED we pay a federal government license for us to use it. But it certainly is interesting to know what is the total cost of using such a standard.
What is its life cycle maturity? Has it been put live in production anyway? We did look not only nationally, but we looked internationally. We do have to look at what the U.K. and Canada and others are doing, simply because if they have learned lessons with the early adoption of standards such as HL7.30, we learn the good, we learn the bad, and we take into account that life cycle maturity internationally.
Then we get down even further and more granular. What we say is, if we were to choose a suite of standards for a given use case, are they compatible with each other. If you say NCPDP is great for medications and X12 is great for demographics and HL7 is wonderful for labs, and they have no capacity to work together, that doesn't help you a huge amount.
The preferred standards and standards organization characteristics. Are there implementation guides that have been done? Are there a good number of volunteers that have the availability to create as standards mature new versions?
For example, I heard the discussion of genomics, and what are we going to do in the future when there are repositories of all of our gene sequences? Does HL7 have a well-baked, mature standard for the transmission of sequence information from one place to another? Not yet, but we know they need to work on that. So as an SDO, are they capable of doing such work in the future? We want a standard that will be continually mature.
An example of one of the challenges here, E-links, a standard that has been used by many. It is really not a standard, more of an implementation guide of HL7.24 for the transmission of lab data. The California Health Care Foundation did a lot of work on it. It has been embraced by Regenstrief. So it is great work, it just has no SDO behind it. So that means that as HL7 itself evolves, there is not a well-funded body to take on the continued work on E-links.
So what we said was, we think it is great. If you just allow yourselves with HL7 or IHE or somebody, and then maybe bring up that 24 to 25, then certainly it would meet these 2.2 criteria. The folks at E-links said, we get it, you didn't make this arbitrary and capricious decision. It was clearly and well understood and documented what SDOs need to do and what standards characteristics are desirable.
We ultimately want to look at ease of implementation. We found that at least at this point we didn't have a good metric for figuring that out. Is it easier to implement CCR versus CDA, or how do you measure that exactly? You would think if it was a huge expensive barrier to industry to implement a given standard, that should be taken into account. So something that we would do in the future.
A couple of comments on process. As one makes the sausage here, there is the question, are there smoke-filled rooms where secret deals are being made, and of course, the answer is, HITSP doesn't have any authority other than the integrity of its process. If it is a stakeholder based organization done in an open transparent fashion, and people say we all got together and we argued quite a lot, but in the end we all thought we should go this way, then that has some authority in the industry.
So what we said was, every meeting we will have minutes. Every vote will be announced. Everything will be done by consensus. In fact, we try to avoid voting at all costs. In the rare circumstance we do have a vote, we have specific rules for what constitutes a quorum, and votes have not only the vote at the place it is being done, but maybe there are folks that are listening on the phone, or folks that could not attend all the meetings, so we will leave the voting period open for 24 hours to get as much consensus voting as we can.
This is all placed on the web. So when you go to hitsp.org, you will find in our document repository every minute of every committee meeting, every vote, every person who attended or did not attend.
In fact, I have asked for a special panel exception to our bylaws for our September 20 meeting to encourage more voting. In the initial charter it said you are not allowed to vote unless you have been to the last HITSP meetings. We said there have been four HITSP meetings so far, so if you have been to two of the four, then that's okay, any two, or if you have been to one but have been an active participant in the committee process such as the technical committees, that would also suffice. So this is again as democratic, as open as possible.
I will tell you, since our initial draft specifications came out on August 19, I have had over 1500 e-mails from stakeholders on aspects of the process and standard selection. If they say there were no meeting minutes for XYZ committee meeting, it turns out that originally, the post July meetings were put in the pre July folder on the web, but now they are corrected. They are all there. Everything has been to my best examination and audit and due diligence as adhering to an open transparent process as is possible.
A quick rundown on the deliverable schedule. We came up with our draft interoperability specifications on the evening of August 18. We then opened it up for panel comment, and our interoperability testing.
One comment. We recognize this is a very highly compressed time frame. Although all of that testing activity to look into the interoperability specifications and assess their appropriateness is very formal, the first comment period was informal. Get us your comments, tell us what you generally think.
It turns out offering an informal comment period is actually a mistake. We got 704 comments, which were extraordinarily valuable to me and program management. We stratified them, what are people worried about, et cetera. But those folks were commented were somewhat frustrated because we didn't have formal audited documented response to every one of the informal comments.
So as of today we do open up our formal comment period, and that goes from today until the 20th. Everyone will be logged, every comment will be officially responded to. Every comment will have a very specific disposition.
I have a Friday e-mail I send to every one of the HITSP members, and in this Friday's e-mail I apologize for the fact that we have got 704 comments in the course of a week, have read every one of them, couldn't respond to every single one, but don't worry, they will be addressed in the formal comment period.
Then we go through our formal comment review and the panel approval on the 20th. There is in the selection of some of our standards a couple of controversies yet. I have split up the vote in a way that enables the panel to look at each interoperability specification as a stand-alone and say, did it seem to meet the use case, it doesn't meet technical validity.
I have split the consumer empowerment specification into two pieces, what I will call final state and interim state. As you will see, the final state depends upon the continuity of care document, a harmonization of HL7, CDA and the continuity of care record, CCR. That is not finished yet. So fine, we recommended some things in the interim, and folks are more scared by the interim than they are the final state.
So if we can all get to Kumbaya and we all agree on a final state, fabulous. The interim is just a stepping stone on our way there.
So that happens on the 20th. Based on all formal comments and the input at that meeting, we will finalize our interoperability specification over the following week and then deliver them to HHS on the 29th.
People have asked me, so are you done on the 29th? Are you just going to say this first round is finished? I believe truly that we have done one third of the work that is necessary. Fine, we have a set of unambiguous cookbooks, but what about privacy and security? It turns out that HISPC, our folks at the health information security and privacy collaboration, are currently doing an inventory of 34 regions and states, and will give us what we hope are best practices for privacy policy.
It is very challenging to come up with a set of technology solutions before you have privacy policy. We have done some basics; how do you encrypt a transaction, how do you audit a transaction, how do you do authentication. But if we discover that there are very complex privacy policies around documentation of consent and is that down to the doctor level, the institution level, the line item in your problem list? Without knowing that, it is very hard to specify a standard. So I think there is going to be a significant body of work that follows the September 29 deliverable once the AHIC work group on privacy and the folks at HISPC have their deliverable.
Further, I think there needs to be substantial work, and there is some interim work we have done, on the business sustainability of HITSP itself, and how we will continue to keep interoperability specifications up to date. We have CCHIT, we have RIOs, we have HITSP, all those organizations trying to define business sustainability and a very finite set of resources to go around. So that is additional work we will continue to do. And we expect new use cases coming from AHIC any day, such as the first responder in emergency situation use case, chronic care coordination, these kinds of things. We will work on those, too.
One other comment. Along the way here we have had to work very diligently. In six months from getting use cases to deliverables, along the way there are certain things that are really important to figure out, we just don't have the time.
So for example, wouldn't it be wonderful if there was a consistent process for every standards development organization, every organization that builds code sets, and every implementation guide builder in this country to work together in a completely seamless way? So when HL7 comes up with a new version, the folks that are doing implementation guides know how that will be delivered to them, and then when the implementation guide folks make a revision, how does that get back to the standards development organizations, and how does HITSP facilitate all that. That is work we need to do. So we are establishing a committee that will do some foundation work about coordination of SDOs, folks like IHE and HITSP.
Similarly, I think there needs to be additional work done on terminology. In the HITSP standards we do adopt a lot of terminology, but does that imply eery bite of data will be semantically interoperable? Not on September 29, but it will be as good as we think we can get, so that is another bit of foundation.
Just as a comment, folks say they have not solved every issue around standards yet. It is not as if we don't know about them. It is just that we have deferred them to September 30.
Just a couple of terminology items. Recognizing that no presentation could be complete without a cloud and lightening bolts, we talk about such things as base standards, transactions, transaction packages. I don't want this to be dizzying terminology. Basically what it suggests is, recognize the fact that if a doctor says I want Simon's complete electronic health record, that isn't just a question of HL7 having a standard called the complete electronic health record.
They may have a standard that says here is an HL7 message, whether that is a simple push or whether it is a pull, but it may be something that is a base standard. Here is a lab result, but that may need to be wrapped in something that is a little more complex called a collection of transaction of results. Here is the initial, here is the final result, and around that we are going to put some additional information like, here are the reference ranges for these labs, the kind of machine. All of that becomes not just a base standard, but a transaction. But then that transaction package may be a collection of labs for today plus historical labs. But then there may be something even beyond that. An interoperability specification is a collection of transaction package for labs, a transaction package for meds, a transaction package for allergies. We simply built a set of terminologies called base standards, transactions and transaction packages to refer to the layers that may comprise interoperability specification as you go from a single bite to a complete electronic health record.
Don't worry, in the presentation you will find a complete crisp set of definitions of every one of these terms, as well as samples as to what would constitute a transaction package, a transaction, a base standard, et cetera.
Now I get into -- I know this is probably a little challenging to read, so let me summarize this for you. These are the universal modeling language or UML diagrams that have been produced to give the HITSP interoperability specifications a sense of a summary. I did send a long and early draft of these, so you may well have an early incarnation of these in your handout.
Let me start with one of the most controversial recommendations that we have made. This is around consumer empowerment. Consumer empowerment is, how do I transmit demographics and medication information in an unambiguous fashion.
Here is what we had to do. As I said already, NCPDP is a very commonly used standard for medication, both prescribing and history, in the pharmacies and the PBMs and e-prescribing applications. X12 is very common in the payor community and in the revenue cycle to ask, is this person eligible for care, and here are their demographics.
The continuity of care record, the CCR, is commonly used in many provider organizations, especially small doctor's offices and many vendors have embraced this. Hospitals use a lot of HL7. They use HL7 mostly today in a message format. It is a non-persistent format, such that you register a patient, and that information about who they are goes to the pharmacy system, the radiology system, et cetera. A result comes back from the radiology system and how does it populate an electronic health record.
So given all of this set of constraints in NCPDP and X12 and CCR and HL7, how could you possibly harmonize that? Here is what we did. We said, we believe the continuity of care document, the CCD, this work in progress by both ASTM and HL7, provides the best of the clinical document architecture from HL7 and the best of the continuity of care record in a legal document that is persistent.
So this is to say, if I query somebody's medication list today and I get a result back, I am queried again in another year, I say what did it say as of September 13, 2006, you would want to get the same response. Wouldn't it be embarrassing if you said, I am going to prescribe a medication today based on the information that came across in an HL7 message, and then the patient has a catastrophic reaction to it and you look again and the information is different than you remember. That is a problem.
So the continuity of care document says, we will have a header that describes the nature of a document, a medication list, who signed it, what the date of this medication list is, and that medication list will contain information that is going to be represented in an XML format.
How is it that we take NCPDP and CCR and roll those into it? We have mapped the continuity of care record, medications and demographics, the X12 demographics and the NCPDP 8.1 medications to the continuity of care document, so there is an unambiguous way that at the edge of an organization everything will go over the wire in a completely uniform continuity of care document format.
So the best of all worlds is done here. Within an organization you can continue to run as well you should the typical high standards that you have already articulated, NCPDP, X12, et cetera, but between organizations it is in a uniform format called the continuity of care document that is harmonizing HL7 and CCR.
That seems pretty good, but remember, I said the continuity of care document isn't done yet. It is close. It is expected mid-2007. Here is the controversy: What do you pick in the meantime? We have got a lot of choices. We can say, do whatever you want, a thousand windflowers will bloom. You could say we are going to pick one standard, the CDA or the CCR. But whatever you do there, people are going to get unhappy. Or you could say we are going to pick three, and you can use any of those three, but we had to do something.
So the logic was, pick something that will at least give what we think is an early experience in what the CCD will be like, and also pick something that motivates everyone to get the final standard done. The problem is, if you say, oh, CCR is great, let's use that, HL7 is great, just use that, then what motivation will people have to get the CCD finished? They will say, we'll just stick with CCR. It is what we are using today, it is totally comfortable to us.
So this is where of my 1500 e-mails probably a thousand e-mails said, oh my God, have you really screwed up. What we have said here, there is something IHE has come up with called XPHR that probably few folks have heard of. All it is, is an implementation guide for the HL7 clinical document architecture with a little bit of some standards from NCPDP and with some standards from X12 and with some standards from the federal medication terminologies, but it does not include at this point a lot of the continuity of care record stuff. It is the best thing that was out there on the shelf that it gives people a taste of what CCD will be.
So we said, this is an interim standard. What do we mean by interim? Interim means it is not going to be used in any production sense. It is going to be used as a test only to get some early experience with what we think the final standards will be, and it will certainly not be used for CCHIT criteria, because it is purely a transient interim standard.
Again, we are doing this because we know it makes so many people unhappy, it will motivate you to get to that final CCD state quickly. Now you see the controversy and why I have split the vote at the panel. Here is a set of final state, CCD amended by X12, NCPDP and CCR, and all the federal medication terminologies, SNOMED, et cetera. Here is the interim state, XPHR which is CDA and some of these other standards. You decide if you would like the interim or not, if it would be helpful or not. That will up to the panel, not to me.
This is again a UML diagram so it has got a lot of detail, but it shows you the sense that we have included LOINC, X12, NDC, federal medication terminologies, NCPDP, CCD, CCR, CDAR-2.
Also recognize -- and I heard this discussion, that is why I was so happy to be here --
MR. BLAIR: What is CDAR-2?
DR. HALAMKA: The clinical document architecture revision two. It is the HL7-3.0 mechanism for wrapping basically an envelope around content.
We recognize that there may be a couple of flavors of architecture that the NHIN contractors and others may wish to pursue. One may be called -- even though we think it is great to have a persistent document so that it is non-repudiatable. It is legally defensible. This is what we pull on a given date.
There may be reasons to have a messaging architecture. That is to say, here is a transient message that goes between two systems that has information about medications or has information about demographics.
What we have also said is, if there is this absolute need for a transient message, HL7-2.5 for the transmission of demographics between two systems that communicate with each other in that transient fashion, it is acceptable as well. We had to be very careful. We couldn't force an architecture, we didn't want to do that, so we did offer these two options, CCD with all those other standards that I mentioned, and HL7-2.5, where there simply has to be a message that transacts between two systems of record.
So that is consumer empowerment. Let me also use this as a jumping point, and then I'll take questions. You will see here that there are actually a lot of building blocks, like, you are going to transmit a document between two entities? You are going to use a controlled vocabulary? You are going to have mappings between different standards?
Obviously we want to reuse all of those in every other use case that we have. One of the things that we have done, I have put in blue on this slide things that are totally reusable. So you will see as I go into these other standards of biosurveillance and EHR, we are simply reusing those.
It was very challenging, given that there were three separate panels working on these three separate use cases to insure that you didn't have, panel A is going to recommend CCD, but panel B is going to recommend CCR. So we developed this idea of functional content specific packages that could simply be taken off the shelf and reused for any use case, creating consistency across all three interoperability specifications.
Question?
DR. STEINDEL: Just a clarification, John. When you were talking about E-links, you noted that one of the problems was that there was no SDL maintaining it. SDL is maintaining CCD in this format.
MS. HAMMOND: It is a joint HL7-ASTM --
DR. STEINDEL: So they have stepped up to that plate?
MS. HAMMOND: They have done that, yes. In my Friday e-mail I go through in copious detail how we have resolved the HL7, ASTM and IHE controversy. I say all of us in the community must support HL7 and ASTM as they harmonize and continue to support the CCD.
I do want to leave plenty of time for questions, so let me go through these others very briefly. I used that first one to give you a good example, but similarly on the electronic health record recommendations, very similar. We said it would be good if you had a lab in a document that was non-repudiatable, so if you had a serum potassium of two, when you look next week it still said two rather than a transient message, this was the interim, this was the final, let's change four times. But we recognize architectures may require the transmission of messages between two entities as well as documents. So similarly, we said fine, we'll support publish-describe, we will support push, we will support pull.
Here is the context. It is a document. That document is a CCD document that is based on the HL7, CDA, R2 and does have LOINC codes specifying vocabulary, and if you need a transient message, there is the HL7-2.5 flavor that will also support that. So you are looking at the reuse here, demographic, the reuse of documents, and the base standards being HL7-2.5, CDAR-2 and some of the IHE standards.
Did you have a question? Go ahead, please, let's not lose the moment.
MR. BLAIR: How were you able to get consensus agreement on HL7-2.5? I'm sure there were a lot of folks at HL7 that were concerned that that might defer HL7-3.0 even further in terms of adoption. So what was the understanding that was reached to get that consensus?
MS. HAMMOND: Sure. We looked at all the flavors of HL7 and we said 2.3, 2.4, 2.5. We first said what is in use today in the United States? 2.3. Is there 2.4? A little, not much.
We said, what is the barrier from going from 2.3 to 2.4 versus the barrier of going to 2.3 to 2.5? What are the benefits of going to 2.5? Blood bank is now supported. There are a whole variety of additional goodies there. So HL7 said, the bang for the buck versus the effort is worth going from 2.3 which is used today to 2.5, which we all think is pretty good. We know that 3.0, that is in use in other countries, and they are having some experience with it, and it is part of the CDA, so we are going to get that there. But we do think that if you are going to have something by September 29, that 2.5 is your best bet.
Then this last one, the biosurveillance, was one of the least controversial. It was the same kind of architecture. It is the document that is going from place to place or the option of a message going from place to place. Same standards, HL7-2.5, HL7-CDAR-2, and the laboratory messages that are informed by LOINC terminology.
One comment here. There are some gaps, as you might guess, on the biosurveillance side. So for example, what standard do we have in the country that you can simply use to anonymize an incoming transaction perfectly? Don't quite have that one yet. Or pseudo anonymized. I want it anonymized from the Centers for Disease Control perspective, but when they discover an avian flu index case, we need to be able to rapidly re-identify them patient. So that is a bit of a work in process still. Just recognize, we have stipulated what the inputs and outputs need to be, how that needs to function, and we will continue to work with the SDOs on some of those anonymization issues.
This is the schedule we used, where we used a very, very rapid testing schedule. We sent out on the 18th a set of documents with all the detail I just showed you in the UML. It is about a thousand pages of documents behind that. Then we went through day by day all of these teleconferences, about five teleconferences and interactive video sessions, gathered all the input, met in Washington last week. Did formal disposition on every single comment, on every single test, and received finally an end point, and have now got a set of documents that we posted on the web today.
Just a quick comment. Those testers looked at the basics, was it readable, did it meet the technical requirements and use case requirements.
I just want to show you. In testing we got positive and negative comments. Obviously this was not any kind of rubber stamp. A lot of the negative comments were on, so what is this interim standard that you are thinking about using. When you look at this you say, I see 90 percent or 89 percent, 37 percent; 36 percent of testers thought that was good. That was reflective of two things. One, a highly compressed time frame for looking at a lot of this stuff and two, that interim standard that was perceived as controversial.
As I also mentioned, we broke things down into highly reusable packages, and managing and sharing of documents, sharing results, push versus pull kinds of transactions, and there were those who voted on those. Most of these are in 80s, 90s, and a lot of good feedback on those common packages.
Then finally, just to show you the 704 informal comments broken down into editorial mechanics, content pertaining to selection of standards, and then the processes we used. You can see only a couple of people said the process is flawed. A couple of people said, CCD, the process suggests a standard be adopted that isn't yet formally finished, and that is somewhat frightening. But of 704 comments, 37 to that degree.
A summary for you. Fifty volunteers did the special testing through five teleconferences. All of this work has been done through 12,000 hours, 206 organizations, technical committees meeting diligently. We met face to face last week. We made final corrections, posted all those final corrections on the web this morning at about three in the morning, and now we will get public comments until the 20th. We will reconcile all those public comments, present them to our panel, get a vote on the 20th and final revisions post the 20th, delivery to ONC on the 29th.
That is what we have been up to. I now open it to your questions, and I'm sure they are going to be good.
DR. COHN: John, some very good work. I have two questions, but first of all, like everyone else I want to congratulate you. It is wonderful seeing the industry moving forward in this sort of a fashion.
The two questions I had for you, one is in relationship to conversations we had about the NHIN functional requirements even before you came into the room. The other one is more a question of sustainability and updating and all of this of everything that we have seen.
The first question is around patient matching. We have been having a number of discussions about the role of standards in patient matching algorithms and whether there is a role or not. So that is question number one.
Then question number two is having to do with the standards that you are describing. I am well aware of doing things on a time line. We all spend all of our lives doing imperfect work because it needs to be done yesterday. Yet we are trying to move the industry forward in a way where they aren't constantly having to make adjustments to fix all the problems.
So the question from my view is, I know you have future standards and probably even those are subject to change, and how are you going to be handling that. So the first question about matching algorithms, the second question about issues around changes.
DR. HALAMKA: Both excellent questions. As I said, HITSP did not prescribe an architecture, it prescribed a messaging standard. What we said was, we think it is extraordinarily important to have patient identification that is across organizations, and therefore here is how we will do it. We will issue an HL7 message that has name, gender, date of birth and other identifiers that may be appropriate, and you will return a corresponding message that has the medical identifiers.
How that is done inside the black box, we have not specified. In Massachusetts where I put on my other hat as the CEO of the RIO, we have used the initiate algorithm and we have used the Shawn Grannis algorithm from Regenstrief, and those happen to be probabilistic statistical matches that give us a few false negatives, but no false positives, or so few false positives it will do no harm.
We felt that that is good enough. But did HITSP adjudicate you must use the Shawn Grannis algorithm or the threshold for false positives is one in ten million? We didn't, just the messaging standards that go in and out.
With regard to sustainability, we have presented a business plan to ONC that is part of our September 29 deliverable as to how we will be funded. We recognize that the government funding will not persist forever, but we believe as a major payor the government should have some role in sustaining us. So it is payors, providers, SDOs, the vendor community for various deliverables that we create on their behalf that will pay us and the government, and what will the organization do? It will constantly update the interoperability specifications in a version controlled fashion, so as new standards are issued or new use cases come out, we get new transaction packages, and if there is a new transaction package called the probabilistic statistical matching algorithm, then we are going to have to work on that.
This is why I described standards are not a product, but a process. People have asked me when will HITSP be done. I think the answer is, there will be harmonization for as long as I live.
DR. COHN: Other questions?
DR. FITZMAURICE: On the interoperability specifications, I think that probably no job could have been done better in the time that was given. Yet everybody would like to have had more time. Is there a portion in the ONC contract in the HITSP procedures that would say, we have gotten comments back from ONC and maybe from AHIC, and we will devote some time to addressing those. Plus, some of the things that we have to think of from September 29 to that point. Is there some research available?
DR. HALAMKA: On the one hand you want to constrain the time so it is a forcing function, so you get the work done. On the other hand, you don't want to ignore what is valuable input.
John Loonsk and I had this conversation at our board meeting on Friday. I said, what if the panel says we approve this work, but qualify that if this particular transaction needs additional work, let the technical committees in October and November finish up this part of the project. Does that constitute fulfillment of our contract deliverable?
I think John's answer, and I'll just summarize it, is, as long as you get to the majority of what you said you would deliver, if it is 80 percent delivered back to the committee, that is not so good. If it is 80 percent approved and 20 percent delivered back to the committee, maybe that is tolerable.
So I think in telling the panel what they can vote on, I have said approve the qualifications requiring further review by the technical committee or disapprove, are the two choices.
MR. BLAIR: I am going to be a little obscure in this question, because I am not going to name the name of the entities. But there have been certain organizations that have produced de facto standards that are proprietary, that are really quite good.
I am wondering, as you went through this process, whether there was both a message that went out to those entities for them to understand that for something to be a national standard it had to be census based. It had to be developed by an open SDO. So I wonder if the message went to those entities to realize that having proprietary standards is not likely to be accepted in the future.
The other piece is going the other way, did it go back to either ONC or HHS to wind up saying where there is a really good proprietary standard that is needed to fill the gap, that we might have to go through a process similar to the one that we went through with SNOMED and CAP, to make sure that is available at no cost to everyone. Did that happen?
DR. HALAMKA: Some very good questions. Recognizing that we have had to take the emotion out of this, and of course part of the emotion was proprietary business interests, we established a harmonization readiness committee as one of our first acts. The harmonization readiness committee put volunteer stakeholders together and came up with a set of objective criteria to say whether a standard was appropriate or not.
Then we broadly circulated to all the technical committees and all of the HITSP panel membership, these are the criteria we are going to use. It was developed in a garage by two guys and it is a million dollars a copy. Probably not a good national standard, because there has been very little pushback from the proprietary standards world. They have said, we get it, that does seem to make sense.
I will tell you, at least so far in our deliberations we have not found the need for one of those proprietary standards to be included in our final recommendations. If that was the case, then certainly we would go back to ONC and AHIC and say we do need to sign a contract with XYZ vendor because SNOMED is a great thing and we are glad you did it. As long as SNOMED is licensed, we think we are good.
But as we go forward with the different use cases, that may happen. We will keep it in mind. At the moment I do have many phone calls from the CEOs of companies that make proprietary standards, but ultimately they understood our criteria.
Other questions? There must be questions.
DR. COHN: As we move forward around NHIN standards, we want to continue to have conversations with you. But we are very pleased with how this is going. Certainly many of us have histories of being involved in previous efforts to bring the standards organizations together supported by ANSE and others. It is a difficult thing to pull off. So we do appreciate your ability to handle this so far.
DR. HALAMKA: People ask me what prepared me for the role of HITSP, and my answer is my training as an emergency physician. It is all about triage. If you have the ASTM and HL7, it is easy.
DR. COHN: Thank you very much again. Congratulations.
DR. HALAMKA: We hope the 20th goes well.
DR. COHN: Going back to the things we were talking about before, I think we have gotten agreement from the Populations Subcommittee to stay around for another 20 minutes. We have two items. One has to do with the letter on allergies that I wanted Harry to go to directly as the next item. This is one we need to review to decide whether it is an action item for today or tomorrow. Then I think we want to spend a little more time going through the remaining parts of the NHIN recommendations.
So Harry, I will turn it to you.
Agenda Item: Subcommittee on Standards and Security Letter
MR. REYNOLDS: The letter is in front of you. It is one of the more brief ones you have heard from us. So since it was brief, we decided to add about 28 pages behind it for your perusal.
I will read the letter quickly to you. The National Committee on Vital and Health Statistics appreciates your continued support for the consolidated health informatics initiative, CHI, as evidenced by its widespread inclusion in many federal solicitations.
I'll step out of the letter for a minute. As just recently discussed by John Halamka very clearly, at the appropriate time all the CAS stuff is being incorporated into what they are doing.
This recommendation letter continues a role that NCVHS has played in the CHI council acceptance process. In this role, NCVHS provides an open forum for review to CHI standards recommendations and provides an independent assessment of these recommendations.
Enclosed are the CHI recommendations on the allergy domain. The NCVHS concurs with these recommendations. The NCVHS recommends approval of the CHI standard by the Secretary, and formal government adoption.
We are pleased to continue our role in the CHI recommendation process.
What I am going to do now is have Steve Steindel take you through the five recommendations very quickly. Then we will see what your pleasure is.
DR. STEINDEL: Jeff just whispered in my ear.
MR. BLAIR: For all the rest of you who have not been with us when we have gone through the NCVHS role with respect to the CHI standards, please note that there is a slight difference in this process. We are talking about CHI recommendations of standards, and whether NCVHS concurs or does not concur.
So we are not recommending, we are concurring or not concurring. That is why those words are there. It is a little different than most of the other letters.
MR. REYNOLDS: Steve.
DR. STEINDEL: We have two points in the appendix to point you to. The first is on page two of the appendix document. That lists the five standards that are being recommended in the area for allergies. They are HL7 version 2.4 and higher for information exchange. There is the unique ingredient identifier or the UNII for a whole series of various different terms. This is an FDA internal vocabulary set that is being used in many areas and has been a previous recommendation of CHI for the medication domain. There is RxNorm, which is a part of the National Library of Medicine and contains a series of vocabulary codes for different types of allergy recommendations.
I am being vague here deliberately, because I am going to point you to another spot in the document.
The next is item number four, which is NDFRT, the national drug file reference terminology, which is being developed by the VA for allergen groups and drug classes that is needed to support the description of allergies in this area. Finally, there is SNOMED for its clinical terminology in these areas.
Those are the five terminologies that are being recommended for the allergy domain.
Now I would like you to turn to page 12 of the document, where they have a summary of the recommendations. The key part here is in the allergy domain. Here they are talking about the various descriptions that are needed to describe an allergy from a clinical point of view and what type of information is needed there.
MR. REYNOLDS: This has a chart at the bottom of the page.
DR. STEINDEL: Chart at the bottom of the page 12. You will see that in some of these allergy domains, more than one standard is recommended. Generally it is one. The main one where it is not one is the allergen name, mnemonic and description where they are recommending the unique codes from the FDA and also the SRS, substance registry system. I should know that because I was the one that recommended that for chemicals, but that was too many years ago. And the EPA.
The reason both are recommended is, they are supposed to be harmonized with each other so you can use either one. So they appear in two locations. You will see in a much clearer fashion on that chart what each one of the various standards that are being recommended are being used for in the various parts of the allergy domain.
You will also see that this is an extremely complex domain. It was very difficult to describe all the aspects of an allergic reaction or allergies, so that we can transmit the information in a meaningful fashion. It took this group I would say several years of discussion followed by several years of hard work before this was put down like this.
You will also notice on page 13, this is not complete. There are areas of these standards that are being recommended that are still under development. This is not unusual in a CHI recommendation, because what CHI is trying to do is identify standards that are ready for use today that also push the development of standards to fill gaps where they exist.
Primarily these are missing gaps in some of the unique code areas. We are recommending here that unique code not be fully adapted until the gaps are full. This is a push towards FDA and towards HHS to provide a process to fill these gaps.
The unique code we did describe earlier, Jeff. That was the unique ingredient identifier.
When we say we concur with the recommendation, we are concurring with this package, which does contain this conditional area. So it is understood that we do mean that those areas that are not conditional are going to be -- we concur with their use today, and we concur with the CHI recommendation that the conditional areas be filled.
So that is my summary of it. Beth, do you have anything to add there besides my fumbling over some acronyms over many years?
PARTICIPANT: No, thank you, Steve.
MR. REYNOLDS: I would add one other thing. At our hearing Beth brought a cast of thousands with her that represented about every part of the government you could imagine. They were all in concurrence also, and we had them stipulate that.
So this is a representative group. It was a good cross section. So we are taking the recommendation a little bit like John was just talking about on his whole process. We had pretty much that whole team there, either on the phone or in person, explaining that they were in concurrence with this and that this was the right thing to do.
MR. HOUSTON: I make a motion that we approve the letter and the recommendation.
DR. STEINDEL: I second.
DR. TANG: Let me just check on an assumption. In order to correctly store allergy information about a patient and to exchange it with another group, you would comply with all five standards. So the assumption which I got is, in the FRT we would have to use RxNorm in order to be able to identify the individual drug.
MR. REYNOLDS: Beth, do you concur with that?
PARTICIPANT: NDFRT is being recommended for the actual drug classification name. RxNorm is the brand name. So infrastructure, I think an example may help. A patient may come in and say I am allergic to sulfa drugs. Another patient may come in and say I am allergic to Bactrim. So we have to have a way to transmit both those different variations from an allergy standpoint.
The HL7 messaging transaction allows you that flexibility, gives you that flexibility to transmit that type of information. What we have done is identified where to find that terminology. So RxNorm is already a CHI endorsed vocabulary, and it does store the brand names for drugs. The NDFRT is already a CHI endorsed vocabulary for drug classifications based on mechanism of action and physiological effect. We are expanding that for chemical classification as well for the allergies.
DR. TANG: First of all, when you said brand names, I assume generic is in RxNorm as well?
PARTICIPANT: Yes, it is.
DR. TANG: If you do declare sulfa, and sulfa maps into a number of drugs and chemicals, those chemicals contain the RxNorm identifier?
DR. STEINDEL: Yes. Going to Beth's example, if you had a patient come in that said they were allergic to Bactrim, you would use the RxNorm indicators to say this patient is allergic to Bactrim, and transmit it to someone else.
Now, you may also cross reference within the UMLS the relationship between RxNorm and the MDFRT drug classes and say, this is a sulfa drug. You may conclude that the patient is allergic to sulfa drugs.
DR. TANG: So that gets to the point I am trying to raise. Do I require UMLS in order to make that mapping into the correct drug class, either pharmaceutical therapeutic class or chemical class, and vice versa? When I say I am allergic to this class of drugs, will I require UMLS?
PARTICIPANT: I think part of what you are describing in our discussion is how does the application work within the provider industry, as opposed to how do we transmit that information.
Within a hospital system, say we are talking about a hospital system, there are several vocabularies that they may use to do exactly what you are talking about. There are some proprietary vocabularies and there are some federal public vocabularies.
What the CHI recommendation says is, if you are going to transmit that information regardless of what you are using internally, but when you go to transmit that information, the vocabularies you will use are RxNorm for the brand name and the NDFRT chemical classification name.
DR. TANG: That is interesting. You are basically disassociating the mapping between the drug class and the drug from these two messaging standards, is that correct?
DR. COHN: So I think there is not a specification in the standard, because it doesn't have to be exactly the nature of the structure, by UMLS or by a proprietary company who does the structure, as long as the class names and the medication, not the brand name, but the medication name is used, which is what RxNorm is.
DR. STEINDEL: Paul, on NCVHS we have had a lot of discussions about medication. But what FDA and VA want to do is use the RxNorm, NDFRT, UMLS link to derive the knowledge.
What was done in the CHI recommendation is separate out the knowledge.
DR. COHN: We have got a motion and a second. Is there other discussion? Is it the desire of the committee to vote on this today?
PARTICIPANT: Question.
DR. COHN: The question has been called. In that case, all in favor?
(Chorus of Ayes.)
DR. COHN: All opposed? Abstentions. The motion passes. Congratulations.
PARTICIPANT: Thank you very much.
DR. COHN: I'd like to comment before we move back to the letter and the remainder of it, this we all recognize has been an extraordinarily difficult area and complex. We want to congratulate you. The only area that I think is in any way more complex is disability, which maybe sometime we will see back from CHI as a recommendation.
MS. GREENBERG: Yes, in October.
DR. COHN: Sounds good. Harry, do you want to talk about the rest of the NHIN document?
MR. REYNOLDS: Yes. This is another view where misconception -- Jeff and I could have answered all those questions, but we thought we would Steve and Beth, since they were here.
We are going to move to page 18, and we are just going to read the recommendation there, because we are talking about gaps in functional requirements and how we think it should be addressed.
So Margaret, if you wouldn't mind reading recommendation 12, which is pretty self explanatory. If you will just read that, and then we will get any comments on it.
MS. AMATAYAKUL: NCVHS recommends that HHS support the testing of the high level functional requirements against other very common use cases. These might include e-prescribing and the various exchanges between prescribers and dispensers, and special signature requirements for controlled substances.
Medication reconciliation within a hospital is described by JCAHO and across the continuum of care. Use of clinical decision support by caregivers and individuals, especially as related to differences in data rendering, reimbursement for health care services, clinical research, regulatory reporting and selected services provided by public health departments.
MR. REYNOLDS: The main point again is, you hear a lot about the ONC use cases. We are just making sure that when you talk about the NHIN functionality that it is not just pigeonholed into the three or four use cases that tend to be the dominant discussions around the country.
DR. STEINDEL: I have a question about the word testing in this context. We just heard an excellent presentation from John Halamka, and we realize that HITSP has been under tremendous time constraint. The only testing of the implementation guides that are going to be voted on on September 20 has been visual inspection.
Do you feel that visual inspection testing of the functional requirements against these other use cases suffices, or do you want testing, real testing? I think by my choice of words we have gotten an indication of what my preference might be.
DR. FITZMAURICE: Would you call it implementation testing?
DR. STEINDEL: No, I would call it real testing because I am nasty. But your more politically correct choice of words.
MR. REYNOLDS: Prior to his discussion we thought there was only one kind of testing. We have used the generic term testing in the past.
DR. DEERING: I would only point out that we have nowhere recommended that they be testing, have we, against the other use cases? So let's make sure that whatever way we go, that --
DR. FITZMAURICE: They can implement that, whether it is Kaiser or whether it is VA, DoD or United Health Care, Aetna.
MR. REYNOLDS: I'm not sure. Up until now we have not been prescriptive with the Department. So we are recommending, by the way there are lots of other ways to use this, and make sure those are given the appropriate consideration as you are considering moving forward. That is what we are saying to the Department.
I'm not sure getting more prescriptive -- real testing, we would have to use a new term, as compared to pretend testing.
MR. BLAIR: Harry, if you are putting it that way, is testing the appropriate word?
MR. REYNOLDS: Do you want to give me a better one?
DR. DEERING: Do you mean review?
MR. BLAIR: Something like evaluation might be better.
MR. REYNOLDS: Everybody okay with evaluation?
DR. FITZMAURICE: I'm not sure I am. How about including testing and evaluation?
MR. BLAIR: This is a recommendation. When you have the word testing, I think it means that you need to identify whatever problems there are before it is adopted for these other use cases.
I know that from a realistic standpoint, in all cases they may not be thoroughly innovation tested and component tested and quote real tested. But gosh, if we lower the barrier to evaluation, I would rather stay with the word testing, and if they have to do something that is less than what Steve refers to as real testing, then at least we have made as much progress as we can. But I am hesitant to lower the bar.
DR. FITZMAURICE: Steve, you weren't talking about lowering the bar, were you? You were talking about keeping it at a high level.
DR. STEINDEL: I was talking about raising the bar. I really don't object to the visual inspection testing that HITSP just did in most cases, because they have picked standards that have been implemented. What hasn't been tested is the use of some of the terminology for some of the use cases, et cetera, which would be difficult to test.
DR. COHN: In the interests of time, this feels to me like an NCVHS work group conversation, and we seem to be dealing with words of art. I think we want to make sure that we are getting the important comments from the rest of the committee in the remaining four to five minutes before they are going to leave.
DR. STEINDEL: Simon, I am happy to defer.
MR. REYNOLDS: Any other comments on that? Moving to recommendation 13. Let's just read the recommendation. The key thing here is, just to show you, I'll just go through and highlight them rather than read every word.
We were not asked to deal with the policy issues related around this. We were asked to deal with the functional requirements. However, as we identified a policy question, then we highlighted those here, and some of those came up this morning as you listened to these.
So for example, the first one is, support continued standardization of a certification process. What is the whole process around certification? We identified certification and said what the functional requirements were, but there is a whole set of policy discussions around that whole certification, and some of those came up in the discussion earlier.
The second one is identify and recommend policy for individual identification. We will go back to Russell's comments, we will go back to everything else. What is the right error rate, what is the policy around that? Those are the kind of things that we are trying to deal with.
The next one, C, support the use of standards that will enable the communication of individual permissions or entity preferences concerning specific data. Back to a lot of what we said in the privacy letter and the policies and other things that we recommended there. You can't forget this. You can't just go to functional requirements of a system of systems. There are societal issues and other issues wrapped all around this, but we were asked not to directly adjudicate those. We were there to note those.
The fourth. Recognize the baseline requirements for privacy, security, transactions and code sets are provided for by HIPAA, but that equivalent requirements do not exist where there may be an exchange of health information among non-covered entities. That is what our whole hearing is going to be on privacy in the next few days. It was in the privacy letter. It was clear. Again, not letting any of these things disappear by showing up in one letter and not showing up as a continuous message coming from this committee to the Secretary and others.
Then the last is this whole public awareness. As you have tried to understand this thing clearly, and we use the clear words out of the privacy letter, talking about that it really is understood by people, that they know what they are getting into, not that it is some technical jargon or some other things.
So those are the clean recommendations. We would like you to look at it. So based on the discussions you have heard, are there any other policy issues? If you would let us know as a committee, then we would consider coordinating those. These were the main ones that we bumped into as we did it.
Let's go to the next section, which is recommendation 14. Again, we were not also asked to recommend standards. However, as we ran into these things, just like you run into a policy, you run into things that beg themselves to be some kind of a standard. The first one being authentication codes that support individual permissions. Second, provider preference codes, such as if a provider wants to receive automatic updates; meta data requirements; information location and identity correlation processes, the same kind of thing back to some of the comments we heard this morning, and content standards for certain types of messages, especially relating to evidence detection, alerts and notifications.
So again, as we went along we bumped into these things. They are not part of this. However, we were not asked to adjudicate those matters. We may at a later point or something, I don't know, but we have specified those so they don't get lost in the shuffle.
Then moving to recommendation 15, we recommend that they support further work. Use the high level functional requirements as described in this report as a way to communicate the nature of the initiative that is enabling a Nationwide Health Information Network. So make sure that we keep this kind of thing as a template. That is the high-level functional requirements against additional very common uses. That is the one we just talked about.
Evaluate the definitions of the original functional categories and consider refinements based on industry usage. You will see one of the appendices is how they put these in categories, and making sure that we continue to build a messaging document and a messaging structure to the general public and to others as we move forward with this.
Then the last is, utilize more detailed statements of functionality that illustrate specific use cases and business needs. That also came out earlier from each of you. Make sure that there are examples. Justine hit that clearly today. Here is something we are doing, and here is an example of how it might work and what it might look like. So really trying to continually send a message.
This is a big subject, complex subject. It can go lots of different ways. Words can trip people up. We have tried to capture all these different things, as well as the actual functional requirement that we recommended.
So Simon, that would pretty much complete our review of the document and recommendations. If there are any other comments from anybody on the committee about the last couple of sections that we covered, we would be happy to take them. If not, Simon, that would conclude our discussion at this point.
DR. COHN: Is there any comment, especially from those on the Population Subcommittee? Do you have any comments that you want to make about this?
We will talk tomorrow during our final session about next steps around all of this. I want to thank you for being willing to expose yourself to this. The good news is, it is 20 pages long, it is not 80 pages long.
We do for the Population Subcommittee want to remind you that it is in 341F, not 405A. So don't get lost, either on the wrong floor or on the wrong room.
Before we break, I just want to remind everyone that the quality work group is meeting tomorrow morning at eight a.m. in Room 405. Then we convene the full committee at nine o'clock tomorrow morning. So thank you, we will see you for dinner. Otherwise, the meeting is adjourned.
(Whereupon, the meeting was adjourned at 4:30 p.m.)