[This Transcript is Unedited]
Hubert H. Humphrey Building
Room 705A
200 Independence Avenue, SW
Washington, D.C. 20201
PARTICIPANTS:
Subcommittee Members:
TABLE OF CONTENTS
Agenda Item: Call to Order, Welcome and Introductions
MR. REYNOLDS: Let me call the meeting to order. This is a meeting of the Subcommittee on Standards and Security of the National Committee on Vital and Health Statistics. The committee as you all know is the main public advisory committee to the U.S. Department of Health and Human Services on national health information policy.
I am Harry Reynolds, co-chairman of the subcommittee and I work for Blue Cross and Blue Shield of North Carolina. I would like to welcome my co-chair Jeff Blair, fellow committee members, HHS staff and others. This is a public meeting and we are broadcasting on the Internet. Is that correct? We are broadcasting on the Internet. So, please speak clearly into the microphone at your place.
Also, the meeting is being recorded and transcribed. So, I would like to go around the room and go ahead and do introductions and then we will get into the agenda.
Jeff.
MR. BLAIR: Jeff Blair, co-chair, Subcommittee on Standards and Security, NCVHS. I am the director of health Informatics for Loveless Clinic Foundation and to the best of my knowledge, I do not have any conflicts of interest.
DR. STEINDEL: Steve Steindel, Centers for Disease Control and prevention, staff to the subcommittee and liaison to the full committee.
DR. HUFF: Stan Huff with InterMountain Health Care and the University of Utah in Salt Lake City, member of the committee and of this subcommittee and no conflicts.
MS. AULD: Vivian Auld, National Library of Medicine, staff to the subcommittee.
DR. FERRER: Jorge Ferrer, VA, staff to the subcommittee.
MS. GOVAN-JENKINS: Wanda Govan-Jenkins, NCHS, staff to the committee.
DR. HUNGATE: Bob Hungate, Physician Patient Partnerships for Health, member of the NCVHS committee and visitor to the subcommittee.
MS. PICKETT: Donna Pickett, CDC, NCHS, staff to the subcommittee. DR. WARREN: Judy Warren, University of Kansas School of Nursing, member of the subcommittee. No conflicts.
MS. FRIEDMAN: Maria Friedman, the Centers for Medicare and Medicaid Services, lead staff to the subcommittee.
MS. GREENBERG: Marjorie Greenberg, the National Center for Health Statistics, CDC and executive secretary to the committee.
DR. COHN: Simon Cohn, Kaiser Permanente, chair of the committee and a member of the subcommittee. No conflicts of interest.
(Introductions around the room.)
Agenda Item: Matching Patients to Their Records
This is the afternoon of matching patients to their records. So, we have as one of our key focuses that we have had as a committee and having listened to David Brailer and others yesterday talking about the architecture going forward as far as how we do things across the nation, I think it continues to be a very timely topic.
A member of our committee, Judy Warren, has taken the lead for us on this. So, without further ado, I am going to turn it over to Judy to introduce our presenters and we will go from there.
Thank you, Judy.
DR. WARREN: We have arranged this afternoon to talk about matching patients to their data and I have broken the afternoon up into two panels. The first panel is from the private sector and we have two people who are going to come and testify about what they are doing and then after our afternoon break, we are going to be looking at how various government agencies are addressing the same issues. So, the first people to come up will be Susan McBride, who is with the Dallas-Fort Worth Hospital Council and having talked with Susan over the phone a couple of times, I think you will be really interested in the presentation that she is going to be making.
We also have another presenter, who will be dialing in after Susan presents and her name is Jac Davies and she is with the Inland Northwest Health System in the State of Washington.
So, with that, I would like to turn it over to Susan and have her give her presentation. I told Susan she has got about 20 minutes or so for her presentation with questions after that and then we will go on to Jac.
Susan.
PARTICIPANT: Do we have copies of the presentation?
DR. WARREN: Yes.
DR. MC BRIDE: Some of those slides will overlap into what I am going to present and that is actually the presentation, I believe, that Donna Pickett heard me give at the National Association of Data Organizations. So, I am happy to speak to any of those slides that I don't cover in my presentation, but I have just a slightly different plan on things after speaking with Dr. Warren.
So, I will start by introducing myself. I am Susan McBride and I am the vice president over our data initiative at the Dallas-Fort Worth Hospital Council and I am going to begin by telling you a little bit about that organization and how we are managing data and how we are using data and then where we are headed in the future and what we think the issues are around patient matching and the master patient index or identifier, unique patient identifier, whatever acronym you want to use to describe that indicator.
So, let me just by saying that we are a trade association as the Dallas-Fort Worth Hospital Council. The Education and Research Foundation houses our data initiative and so we also have a workforce center under that to address workforce issues within our region, as well as the data initiative and our disaster planning efforts are also under that Education and Research Foundation.
Those three entities work very collaboratively. We believe that there is a lot of overlap between what is happening in the disaster preparedness arena, especially around syndromic surveillance type data and what we are doing. So, I will talk just real briefly about that and then if anyone has any questions about how we see those things interfacing, I will be happy to address that.
We have a data warehouse right now with over 6 million inpatient encounters that houses our hospitals submission to our public domain data program in the State of Texas, our Texas Health Care Information Collection, under the Department of State Health Services. We are the submission agent for our 70 member hospitals and have built a large comprehensive warehouse around that data set and information. We also have in that warehouse matched hospital discharge data and birth certificate data with over 400,000 births now over a five year period on 41 birthing hospitals in our region.
As many of you may or may not be aware, we have Parkland there in our region that has more births than any hospital in the U.S. Sometimes one of the Atlanta hospitals tips over us. We have quite a bit of information and data on our hospital discharge and birth certificate files. That is where we have done a lot of work around the probablistic linking and algorithmic linking. So, I will talk a little bit more about that very specific project as an example. I won't belabor the technology piece of it because I know after looking at the transcribed meetings that you have heard a lot about the technical, methodological matching techniques.
We support a health services research out of this warehouse -- health of populations served and I will tell you a little bit about some of those projects that also have some of that probablistic linking at the heart of why we are helping to support the activities.
Outpatient data initiative starts in 2006, where we will be getting outpatient data for all our hospital members. We have a regional patient safety and quality collaborative project, the large project we are focused on this year that we will be addressing as medication reconciliation. We are partnered with medicine with our county medical societies, as well as the Texas Medical Association, which has taken medication reconciliation on as one of their three major projects around patient safety this year. We believe that we will be working with pharmacists, our hospitals, as well as medicine to address this issue.
We also believe that it will be the foundation for our RHIO activity around e-prescribing. The CMS quality indicators are routed back to the Dallas-Fort Worth Hospital Council to all members via our Texas Quality Improvement Organization. So, all that information is housed in our warehouse to address primarily patient safety and quality, but what we have found is this information is a robust house of information for our county public health, for our community health assessments and our data is quite current.
It is 90 days out from close of quarter, which is certainly not real time clinical information, which is where we are headed, but it is fairly recent information that can be used. The AHRQ quality indicators, we were -- Texas was one of the beta states, tested the first quality indicators that went out from the Agency for Healthcare Research and Quality. We also picked up on the prevention quality indicators and you will see how we are utilizing those indicators to address some of our community health assessment and our plans around how we are addressing the health of our population.
We also run the patient safety indicators as well. Over 70 measures are housed in our warehouse. We have web-based analytic tools that examine population trends, quality of patient safety. I am going to run through a few of those reports. I won't belabor that.
RHIO activities were initiated in 2005 and I will speak to some of those activities as well. As you can tell, we started out as the submission agent through our hospitals, through our public domain initiatives, but our primary concern was not that submission to the state to meet public domain mandate. It was to address patient safety and quality and to begin to collect data regionally in our information.
Those conversations started in the early nineties out of our area. Our legislation went forward in 1995 and was funded in 1997. So, our region of state in front of -- beginning to use or trying to use data as effectively as we can, collaboratively among our hospitals. We have recently been funded also by an NIH grant under AHRQ to push the technology we have created for our urban hospitals out to 66 rural hospitals. We have approximately 40 hospitals, rural hospitals, in our warehouse now. So, we have this core of urban, but now we also in partnership with Texas A&M, the Health Science Center, they are reaching out to the rural hospitals in the State of Texas. And as you may be aware, we have quite a few hospitals in the state, primarily the largest population of our hospitals is rural.
So, we are beginning to look at how well what we are doing is actually going to work for our rural hospitals in Texas. This is what the interactive web-based tool looks like and these are the AHRQ patient safety indicators. What we have done and we are a business associate partner under HIPAA with all our hospitals.
What I want to show you is just this little check right here. This allows our hospitals to drill through to who is in the numerator population of their patient safety events. These are all the patient safety indicators and here are the hospitals. They are sharing this information, using it collaboratively, trending it over time and then a hospital can actually decide and that is authorized by our CEOs, who within their infrastructure, quality and patient safety can access that drill through. It is protected by firewalls and what they will do is drill through the information, allows them to track trend, look at things like failure to rescue and what is going on in that patient population in order to address those concerns.
We are also launching that with our quality indicators, looking at the mortality within our region in that same manner. What we are doing is trending all our mortality indicators, our prevention quality indicators and our patient safety indicators. You can see -- and we believe that this is reflective of the CMS activity around our process measures, around congestive heart failure, which we are going to begin to get back from our QIO, to put both of these things, both outcomes and process of care, against each other to see where we have got opportunity for improvement. Here, we are clearly doing well and we believe it is reflective of what is going on in the nation around those congestive heart failure measures, process measures.
If you look at congestive heart failure, using the prevention quality indicators and these bump up against the denominator population is the census data. So, this is actually where the patient resides and the admission rates in that county up against the census. So, this is 2000 data. If you watch the red counties, you can see that not only have we got CHS mortalities trending downward, but we have congestive heart failure mortality rates increasing, which tells us we really need to up our clinic activity around CHS. We need to manage their medications better, which ties to our patient safety initiative around medication reconciliation and we actually believe that the congestive heart failure population may be one we really hone in on and see how effective we are being with our medication reconciliation project and may look at as an end point to that intervention, CHS readmission rates across all entities, which again pulls back in that linking, which we need to be able to do in order to get to readmission rates across entities.
This is 2001, 2002 and 2003, which you can see those congestive heart failure admission rates increasing over time. Something else we have been looking at from a population health standpoint and are very concerned about the rise in the methasone resistant staph that we are seeing in our region. This is trending upwards. This is using ICD-9 coding data. So, the preexisting on admission flags, I am anxious to talk to Donna Pickett about what she is doing around the guidelines for this activity because what our hospitals are telling us is that their intention and control programs are indicating that their nosocomial infections are flat or declining.
So, this is coming in out of the community, we believe, with this incline. What can we do about this steep rise in the MRSA? One of our esteemed epidemiologists in our region, Dr. Robert Haley, almost two decades ago wrote an article, "MRSA, Are We Just Going to Have to Live With It?" We hope not. So, our region is really wanting to try to take this on in partnership with public health, to try to create some intervention that will address this.
2006, Patient Safety and Quality Collaborative, I have talked a little bit about this already. So, I am not going to belabor this since I have quite a bit to cover here, but we believe one of the things that is clearly a foundation for any regional health information organization is going to be the security of privacy piece and that trust of the health care consumer is at the base of any successful organization in order to be able to share real time clinical information and effectively use it.
I am going to speak just briefly about that in closing. So, I am not going to go into that much more.
Patient matching and a master patient identifier, this was what Dr. Warren asked me to speak about. What are we doing around algorithmic linking and how effective is it for us and do we believe that it will work for real time clinical application. So, I know that you have belabored the methodology points. So, I am not going to necessarily go into too much of that.
Major purposes as we see it, though, we do believe that it is useful for disease surveillance. You can look at quite a bit linking to other registries, birth certificate, death certificate, hospital discharge data with all three. I think Washington State has done some remarkable work around that and there is a lot of scientific literature around how those data sets can be used to not only look at disease surveillance but also help services, researchers research interventions and how effective those interventions are.
Outcome measures, we definitely believe and are using it to look at our outcome measures in our region, but it also augments data through the linkage, where you can actually compare data sets, like the birth certificate and the hospital discharge data. We have done a lot of work in our region around looking at induction ranks and primary cesarian delivery rates and what is the effect of inductions on primary cesarian delivery using our linked birth and hospital discharge data set.
What we know is there is disagreement in what one data set said, was there an induction or was there not an induction. Cesarian is actually -- there is a lot more agreement on that variable, but you can actually use the data sets to tease out what is valid and reliable information and when they don't match with regards to an intervention or an outcome, what is in that data. Is there a bias introduced when you don't have a match?
Yes, we do see bias. So, that is quite a lengthy discussion. I won't necessarily go into that. But it is excellent for augmenting looking at information with a more robust data set. The -- linking versus probablistic linking, we have actually used both methods within our hospital council. It depends on what we are looking at and why we are looking at it as to whether or not we go one direction or the other, but we prefer probablistic linkages.
I know you have had a lot presented on the differences between the two. So, I am not going to necessarily belabor that issue.
MR. BLAIR: Please don't skip over those. Those are major issues that we are very interested in and why are you using each one and how did you do it.
DR. MC BRIDE: All right. I do have some slides on that and deterministic is an exact match. It is created on one or more matching variables between data files and you want to use a shared unique identifier across the data sets and a unique ID, theoretically error free and not missing. So, sort of the fundamental of dynamanagement(?) that most DBAs, database administrators, and that kind of thing will tell you is that you need a unique key in order to match two files.
Well, in health care, we very seldom have that unique key. So, we have to create mechanisms in order to match data and a deterministic link is what you want to link if you are fairly confident you have got two files that have the same data in them. And you can use more than one variable to actually link it. But you have to have consistency in order to use deterministic methods.
What we see in large data sets, particularly in the clinical setting, as well as our house data warehouse, within the Dallas-Fort Worth Hospital Council, it is very seldom that there is a unique ID that is error free. So, probablistic is a method that we typically use. It is a lot more cumbersome. However, it calculates the likelihood of a correct match, while allowing for incomplete or error conditions within the records to address those errors.
So, why do we do this? Well, names are abbreviated differently. Nicknames are used in one data file and not in the other. Two last names may be used. First name and last name are swapped. You might have misreported dates or parts of dates that are swapped. You may have missing data in other areas. The missing data is a big issue. So, when you are using multiple fields and you have missing data and/or transposed numbers, that introduces challenges with regard to the linkage.
The Dallas-Fort Worth Hospital Council projects that were currently in house using these techniques on are the birth certificate data and the hospital discharge data that we have talked about that we have done for some time now, over five years of linked data. But we also have quite a few health services research projects, too, which are NIH funded, a domestic violence project that is linking our crime data in our Dallas County with the domestic violence looking at substance abuse and both the perpetrator and the victim to see what the association is between substance abuse and violence and hospital admissions with regard to mental health. So, they need us to link the crime file with the -- and we are in the process of developing those probablistic linking methods right now for that study.
Cardiovascular longitudinal study has been ongoing for about five years now, where we are in partnership with UT-Southwestern and we are linking the readmission of a longitudinal cohort that UT-Southwestern is following across I believe it is ten years, it is a ten year longitudinal study, that is very similar in design to the major cardiovascular study that was done a number of years ago.
This is oversampling of African Americans and we have been doing that, as I have said, for about four or five years now. Readmission rates for elderly chronic care condition, there is a proposal out there now for us to look at one of our major systems and to link their chronic care elderly cases across all of our hospitals with regard to admission and they want to create some interventions and then try to address some of their elderly chronic care conditions and we believe that this may be the model that we can use for our entire community to address our medication reconciliation and those endpoint measurements that I talked about potentially around congestive heart failure.
An evolving project is the tracking of MRSA patients across health care delivery systems as a region, working to create an effective community intervention. So, we are going to be looking to link some of those methasone resistant staph cases and see whether or not we are going to work with some of our sociology, demography type experts within our community and research colleagues, to look at whether or not we have pods of MRSA generated out of a certain region in our territory.
Linking in and out patient delivery will be deployed in 2006 as well. So, an example of matching projects to go into what Mr. Blair requested, we are taking the birth certificate and the hospital discharge data and linking it. We are also adding in the American Hospital Association data and we have linked historically a neonatal survey on what is the level of NICU that these hospitals have.
The steps to the matching, the first step is to parse the data into fields that can be standardized. So, there is a lot of data management around doing this and it can be automated, where your code is capped and you run it against the same data set and actually we are working to automate this process right now.
The step 2 is we use a tool called -- that MatchWare Technologies actually created in 1998. Dr. Jarrow(?) did some of the really solid work around probablistic matching and created the tool and what we heard from public health at a recent conference that we attended, that this DOS-based auto stand, 4.7, is still what a lot of our public health departments are using. They get a better match than some of the more sophisticated tools, using this DOS-based system and its original algorithms that are built into it. One of the things we are going to actually do is very cumbersome. We are going to test some of the other tools that are out there against this old DOS-based tool to see whether or not we are getting as adequate a match on our birth certificate and hospital discharge data.
So, we used the auto stand tool to actually, once we parse the data to standardize the data and I am going to talk a little bit more about that, but it standardizes such things as a-v-e-n-u-e, avenue and a-v-e or street and abbreviations of street.
The program actually maps these terms into one standard term. So, then it assigns fields and probabilities or the researcher does. We have actually standardized how we are doing this. So, all of this is read pretty routinely, these pieces of it. Once you establish what your probabilities are, it is a fairly standardized process. What you decide is what the allowable error is, within the fields or the variables that will be matched.
Then the match processes run with auto match 4.2, which is the tool that actually came out in 1998, alongside the 4.7 auto stand. What it does is actually an iterative block that matches the data. I am going to talk a little bit more about that blocking so I won't go into that now. But this is what this looks like, as far as the matching process. This is what we do. We do it to get the comprehensive file that has over 250 variables in it.
Hospital discharge data is this is the mother's record. You have got the birth certificate data, baby's record. You run auto stand against it and it standardizes the file of the mother's record and it standardizes the file of the baby's record. Then what you do is run auto match against that linking the two with -- and that is matched with auto match based on that standardization file.
So, then what we also do is we take and run a sequel run against the data that actually takes tags of ICD-9s with comorbidities. So, we can actually look at whether or not the mother had diabetes or whether or not there were birth defects present and that kind of thing. So, we also have a hospital discharge risk factor file that we merge with that file. We merge the AHA survey data with the hospital characteristics in it and then the final file contains three distinct files, all merged together with the mother's hospital discharge data flagged with risk factors and the baby's birth certificate data in the AHA hospital survey data.
We have roughly anywhere from a 93 to 95 percent match rate depending on the year. A lot of our mismatches are multiple births, where we match on the first baby and so we have been challenged with what the right thing to do with multiple gestation is and depending on what the purpose of that data is being used for, as far as research studies, they may or may not need access to the twins or triplets, that kind of thing. So, a 93 percent match is a pretty good match rate for birth certificate and hospital discharge data compared to a lot of the public health programs that are out there matching, such as Washington State, who has done this for a number of years.
Their match rate hovers around I believe 93 to 95 percent match as well. This is the probablistic linking where you block one and then you block two and the reason -- I am going to talk a little bit about the blocking, but I want you to know the dependency on the social security number here. Any of your good solid match rates, such as hovering around the 95 percent, we are dependent on the social security number or some unique number that has been established within a state and there are states that have not relied so heavily on social, but speaking with NADO recently, what we understand is that is not the norm. The norm is that most public domain programs and their public health departments are relying very heavily on the social security number for these types of matches.
If you don't have it, your match is very poor and I think that some of the other speakers spoke to that and actually have done more investigation into how poor it really is in a very scientific manner. So, I was really happy to see that evidence because we knew from our experience that social, when you don't have it, it is very problematic. So, that was an excellent presentation on the flaws within probablistic linking when you don't have the social security number.
The automated and use of blocking, suppose there are a hundred birth records and a hundred hospital records with a one to one match in the other file. You compare every record in each pile with every record in the other pile. It is sort of a simplistic way of looking at it. So, 10,000 comparisons for a hundred matches manually is really impractical and inefficient. So, what the blocking in matching actually does is it is a run of data that is much more efficient. So, the picture that I hope you are getting is a lot of data processing to do this.
So, one of the things that the blocking does is to break these files down so it is a lot more efficient run and computing power now, thankfully, has gotten very cheap. So, the processing isn't such a huge issue, but when you talk in terms of the nation, you know, I can't imagine how this must be for CMS or something like that, which I believe you are going to hear from a little bit. So, it will be interesting.
But, again, computing power is cheap. The technology is -- we don't believe. Comparing records, I already kind of covered that. Multiple passes, what happens if the record is miscoded for months. The record will never be compared with that matching record and the solution is those multiple blocking schemes and looking at different schemes to actually match on that.
The typical steps in the methodology are you press the data to match in the software. Auto match intakes an ASCII file. It is that old DOS-based file. This is what I meant when I said it is very cumbersome. The codes 2000 actually uses an access database, which is the more recent versions of this type of tool. The data format standardization to make the data element formats the same in the data sets matched, as I have talked about before, as far as the standardization and you have the parsing of the names and the addresses.
So, why standardize and parse? I think this, too, was covered, but alternate spellings and Dr. William J. Smith, Bill Smith, W. John Smith, these are examples of how many more combinations might be possible that we could sit here and play with out of these names. It would be tremendous.
So, what does this look like? Well, this is an example of 487 North McKinney Avenue. So, when you parse, you split that into No. 487 and a modifier of avenue. Then the direction is north. So, what you then get out of your standardization tool, which I have talked about is this is where you cover the a-v-e and you would need the Fort Worth spelled out and you cover the misspellings or the possible types of spellings that you might see.
So, then as far as identifying comparison strategies with blocking matching, which variables to compare, which initial rates, all those things have to be decided. So, one of the things I hope you get out of all of this is the lack of -- it is really almost an art more than a science in how we are doing this. So, the lack of standard and, you know, how good is the science or the data manipulator behind this process is really important when you start using these tools.
So, you prepare the matched specification files, both by data dictionaries, the blocking variables for each pass, the matching variables and once all this is done, it is a fairly routine process and we are going to move it to the next step this year where there is not so much interaction with a human being. We are going to move it more to an automated process.
Let's see, I have talked about estimated weights. Weights are automatically assigned for each of the variables being compared by the software that you plug in and decide upon and then a pointer is sized to the matched cases. The cases for clerical review are reviewed clerically. So, when you mismatch, what do you do with those and how do you introduce bias? We review those quite a bit to see what has been introduced, depending on the use of the file, use cases of what the request is as far as access to the data.
The matched cases are not considered in future passes. So, those are set aside. But once again we don't just set aside without looking to see what are in those mismatched cases. The process is repeated for all the passes. Once again, I am just sort of showing you the picture once I have talked about blocking and matching of what our process looks like and the weights that we have established on the key fields that we are matching on.
Let me just review them real quickly. We use a hospital D from the birth certificate data. We use the year, the month, the day. Social security number is a heavy dependency here and then, of course, the mom's residence, where she actually lives and that pretty much -- the date of birth is another component. So, the final result, we have a merged database with mother/baby match.
We have AHA hospital characteristics linked to the unique providers and the ICD-9 flags that I have talked about that are the risk factors within the file and the result is a very robust file of 250 variables. Our public health department is very interested that automating this as quickly as possible and getting that information back out to them because unfortunately our Texas Department of State Health Services data management budget has been cut so short that they actually do this work themselves.
Our legislation around our public domain program right now creates issues for us with regards to linking some of these data sets and we hope to address that in the 2007 legislative session for Texas. Hardware and software requirements again, modern hardware exceeds virtually all requirements. So, that we do not see an issue, have not in the past, don't in the future.
Software options are limited and this -- at the public health conference that we recently talked about where several of us were together talking about how we are managing this process, we talked about the fact that the options -- there are government options out there, academic and commercial. The software commercially ranked is from 5,000 to 200,000 and the 5,000 are those of us that bought into this DOS-based program years and years ago. That is approximately what we paid for that fee for DOS-based.
So, monetarily is definitely one of the reasons we are still hanging onto that old DOS-based tool, but what we also have heard is that some of those Windows-based applications, they are a little bit more sophisticated, don't work as well. So, what we really would like to see and we called for AHRQ at a recent conference to consider maybe some fact standardized code if we are going to continue to do this kind of thing and we believe that we will have -- regardless of whether we move with the National Patient Identifier, there is always going to be a need to do this kind of thing for many, many years to come.
So, we really do need a standard mechanism for doing that and we would love to see like they have developed the AHRQ quality indicators some software text that would describe how one would map some of these standardized data sets in and then some south(?) code developed potentially that would standardize the way that we are doing these things across the United States.
I hope AHRQ or someone is considering that out there. There is definitely a learning curve with it and I think what we have seen with these quality indicators is that we are going through that curve together and learning how to standardize on using those tools together across the nation and sharing with each other how to effectively use them and I would see if doing something like this in a similar way.
So, what are the issues? Probablistic linkage versus deterministic, algorithmic linkage -- and I am using those probablistic linking is an algorithm that you use. It contains error, even though probablistic is one of our better methods for doing that, it still contains error. Recently, when I talked to a gentleman by the name of D. Hock, who founded the V-Surp(?) Corporation. What he said to me was very interesting. When I was talking about this whole challenge that we have, he said would you be okay with me getting your Visa card charge right 95 percent of the time? So, you know, and he said you are talking about my health care information.
So, that was just really -- I had the opportunity to speak with him two days ago prior to coming in here because one of my colleagues said you are going out there to talk about this. You really need to talk to this gentleman first. So, he shared with me just an amazing story of how Visa had established trust and they do have a unique ID number and they are very confident that when I put a charge out there electronically, it is secure. It is private. The transaction occurs and the public trusts that.
So, what did they do to establish that trust? I know that you all have talked about looking at the credit card industry. He has a fascinating story to tell in his book. One to Many, I believe, is the name of the book and I am about halfway through it right now. We are going to look at that as our regional health information organization in our regions and see whether or not there is anything we can pick up on in order to address this issue because we don't think algorithmic linking will work, not for our clinical care. It is not accurate enough.
We know that the privacy concerns are huge and that is where I think regionally we can really regionally we can really partner and get into our communities and educate the public. I don't know how yet we establish that trust or the infrastructure that they will trust, but we have to figure it out. To me, that is what D. Hock said. You know, we had to figure out how 200 banks and a heavily regulated industry that was a mess would trust each other enough to partner.
So, anyway, I think those are our challenges and perhaps more your challenge than mine, although we have got our sleeves rolling up, you know, in the trenches trying to figure it out. So, I think it is all of our challenge. But at the heart of it is, there is no national standard right now.
Match rate dependency, some of the better match rates, I think, depend on the social security number and I want to talk about an issue that we have had recently arise out of that because social security number is frequently used in public health in our health services research. We are heavily dependent on this for what we do right now and we are doing a good job with the data, you know, the probablistic linking and we are addressing some really -- concerns that we need to be addressing with it, but there is an issue that is hovering out there, lurking, that is going to get us, we believe. The social security number is really a proxy to a unique identifier in our mind.
Currently, because there is no unique identifier, what states have done and regions like ours have done is to get very ingenious sort of -- or creative in how we can create a number that works effectively for us to do our job better, to take care of the populations that we are serving. So, in order to link those patients' records with a reasonable degree, we need to use that field and the social security number is the most discriminating variable and I think that was discussed in a number of your -- a couple of your presentations that it is the most discriminating factor. That is where you are going to get the best match regs.
The social security number is not necessarily a unique ID because we know we have got people sharing social security numbers, especially those folks that are coming across the border and they have one of their family members that actually has a social security number. We are seeing quite a bit of that kind of thing in our region with Texas having a heavy population and influx from that direction.
The social security number remains the most discriminating field, though, which means it is a powerful linkage and we are dependent on it. So, how big is the issue out there period? I asked the National Association of Data Organizations to estimate the dependencies on social and they estimate that there are approximately 30 hospital statewide discharge data systems on the social right now in some form or fashion.
But, again, this is all retrospective data, not real time data feeds and we believe that we need those for the RHIO and our public health information networks. We also believe that you can use a lot of that infrastructure dually and that there is not enough money out there to build a system over here that will address public health and a system over here that will address our regional information network.
As we are looking at our health information technology plan for Texas, we are going to be looking at how whatever we do for Texas, we can jointly address these concerns and what we build will work for both potentially. The discussions of where they are in the DFW area, we believe that the master patient index is going to be our biggest challenge and I believe others are saying that as well. We believe that patient participation is a prerequisite to success and that the patient must be engaged and excited about the benefits. They need to be educated about the concerns involved and the integrity of the program and feel confident in it.
We have considered it an opt in, opt out and I think that this has its own challenges because then if you have got some that opt in and some that opt out, what do you do with those that opted out? So, you are back to your linkages that have all that error in them. Yet, clearly, we believe that citizens and people will see the benefit once they opt in. If we build it right -- I hate to use the old trite expression, if we build it, they will come, but if we build it right, if we build it the way we ought to build it, where you and I are going to go through the system and use it effectively and be happy with what we -- our experience we have had, which I think is a huge challenge, having said that, but I think if we build it right, people will begin to see the value and that is our challenge for sure.
We believe they need to be involved in our we are building it in order to build it so that it will be successful. The data model must evolve over time and we believe that there will be a minimum data set established with some demographics and those clinical items that are a must have. So, we are talking incrementally here. Other data elements besides those fundamentals would be determined by goals and objectives and, of course, whatever we do, we want to watch what is happening nationally around these standards and the certification process and what your group decides.
We don't believe that algorithmic matching will work for clinical care. On of our CIOs in the region said this. "If any organization or region uses algorithms to link my medical records, I will request to see the screen to make sure that is me on the screen." Then you have really got HIPAA concerns when patients start saying I want to check that. All we need is a few errors and we lose trust immediately. So, I think that we can't afford the errors. So, any error is too much error.
Systems currently in place that use this method often have multiple strings of records representing one patient and we have some examples of those. We have hospitals that have spent millions to -- because they have encounters that have multiple records on one patient. So, they don't even have the longitudinal within a system or within a hospital. So, our hospitals have implemented these things and I will tell you kind of an anecdotal funny story. We found out that a 90 year old mother had been lying about her age for years, which we all suspected. Now, she says she is 95 instead of 90.
We found it out when we admitted her to one of our hospitals and implemented one of these very sophisticated systems and they said, well, Mrs. Kirstie(?), were you born in 1914 or 1916 or 1918. She had three different birthdays. So, they found it, but then they had all these strings of the electronic record. So, extrapolate that nationally for state or regionally. An incomplete medical record when assuming one is complete could be more dangerous than assuming you know nothing and starting on a full history.
So, we think that there are some real challenges there. The time to implement a national MPI with implementation of a National Patient Index is going to take a lot of time to penetrate all the way through our system. We see it when a hospital -- even a hospital, not a hospital system introduces unique identifier, a master patient index. It doesn't permeate all of their clinical systems. Maybe their lab system is in isolation.
So, they get in to having to create mechanisms to link and that is just one small isolate of what we are going to face as we move forward nationally. So, once again, I think, that Visa model and how they did it is something we ought to look at because they did do it.
This is the big underlying thing that I talked about, this hovering that I think we are going to have some real problems with if we don't figure out how to address this in the short term. Patients are refusing to provide their socials. So, we actually looked into this recently and I am getting sort of the hook here, so I am going to quickly just tell you that sort of the big thing we looked at was the risk benefit here. Risk in the long run does the patient experience.
There have been no violations of HIPAA in our area and, in fact, NADO has told us there have been no public domain data programs that she is aware of that have had a HIPAA violation around the management of the protected health information networks. So, the risk is small. The benefit is huge and actually sharing it. But it is that trust factor again and our patients are concerned about this and how are we going to deal with it. And education we believe is the key.
But we also need to tell them that something else is coming if we can because they are nervous about using their social security number.
So, in summary, the nation, the public at large would -- we believe we would benefit from a national patient identifier. We don't know exactly what that might look like, if it surfaces, yet. We think trust is a factor that is required for the success of it and strict adherence to HIPAA guidelines. Everyone needs to watch everything they are doing with regards to privacy and we, you know, follow those old ISO techniques of documenting everything you are doing around the management of the data.
It will take years to effectively implement the NPI through the nation and to eliminate that dependency and we should look at other industries as an example.
DR. WARREN: Thank you.
I think in the interest of time, what I would like to do is I know Jac Davies is on the phone, is have Jac give her presentation and then we will open it up for questions.
Thank you very much.
MS. DAVIES: My name is Jac Davies. I am with Inland Northwest Health System, Spokane, Washington.
DR. WARREN: Yes. We need just a second to get your slides up, but go ahead and introduce yourself.
MS. DAVIES: I appreciate very much the opportunity to speak with the committee this morning for me and afternoon for you.
I am going to talk a little bit about what kind of an organization we are because that really goes to the heart of how we are using a master patient index and how it relates with the whole issue of RHIO because we have in some ways a unique situation here in the Northwest and in some ways, I think, a model situation that a lot of other parts of the country can learn from.
Have you got the slides up?
DR. WARREN: Yes. We are on your first slide.
MS. DAVIES: Okay. If you could switch to the second one where it says "Overview."
So, I think that that little bit of background will be very helpful for you in understanding the context that we are coming from. So, the master patient index and how we are using it in our organization and then more about the concept of an enterprise master patient index as part of the RHIO that we participate in and then give you some final thoughts about how this, I think, some of the decisions that you are trying to make.
Inland Northwest Health Services is somewhat of a unique organization. We are a non-profit. We are owned the hospitals in the city of Spokane, which is in eastern Washington, in practically Idaho. We provide services to residents across the entire region and part of that is because of the nature of the health care system here in Spokane. It really is a major medical referral area. So, we draw patients from across, particularly eastern Washington, northern Idaho, western Montana, eastern Oregon and also down from Canada.
What INHS does is work to improve clinical outcomes particularly through assuring information access to all of the people who need to have that information to provide clinical care. As part of that, we have become a custodian of what is really a regional clinical data repository. I will talk about that more in a moment. Because we have established this data repository, we are able to maintain strict data structures and to really standardize that data in a way that allows very accurate sharing and comparing of personal health information.
We work as a shared service organization. So, the hospitals that are part of our system and not just hospitals but also physician offices and clinics and so forth have been able to create leverage by collaborating in a way that lets them control costs. One of the things we have been able to with that is to create -- put in place advanced systems that increase patient safety.
A little bit more about what we are. Currently, we have about 34 hospitals, mostly independent hospitals with over 2,500 beds that are participating in a single hospital information system that we operate on their behalf. The majority of those are small, rural, critical access hospitals, 25 beds or less. We also have some very large hospitals, Sacred Heart in Canada, over 600 beds. We have several 300 bed facilities. There is a couple of hundred bed facilities and then the rest are all smaller.
Again, when I say that there are facilities, I mean, they are participating in our network. We do not operate any of those facilities. Because we have this integrated information system, we have been able to set up a lot of processes for information exchange. There are a lot of physician offices in our region that have electronic record systems and we have set up processes to do standard HL7 messaging between our hospital information system and those EMRs.
But it is not just our hospital information system. We also have worked out arrangements with a regional reference laboratory and a regional imaging center, as well as a national laboratory, where they go ahead and they send data through our system as well. So, any physician that needs access to either inpatient data, to laboratory data and imaging data, they can go get that from one place. If they have an EMR, they can get it via standard messaging. If they don't have an EMR, they can view the data via a virtual private network through a variety of interfaces.
They can also, if they are going to the hospital, they can download the data wirelessly onto their PDAs. So, they have pretty much done away with in many of these hospitals with the paper chart that the physician carries around. So, they are accessing the data, as I said, on their PDAs.
We also are working on implementing computerized physician order entry in a number of the facilities. That will really complete the loop. The physicians can both electronically and -- can both view and enter data electronically.
Another piece of our system is a large telemedicine network. So, we have also done quite a lot to integrate the concept where the telemedicine system has some interesting projects going that way.
We should be looking at a map and that map is just to give you a sense of where we are geographically located and the scale because the scale is quite large. We are talking about a very large rural area, a lot of very small towns. Spokane is the largest population center, as well as the largest health care system east of Seattle and west of Minneapolis. So, that is why we have such a large patient draw.
Most of the facilities we provide services to are in eastern Washington, northern Idaho, that region, but we are also now starting to link up with hospitals on the west side of Washington State, as well as into southern Idaho.
I have been talking about Inland Northwest Health Services and now I want to talk a little bit more about the community governance process. INHS is, as I said, owned by the hospital system here in Spokane and really exists primarily to serve the hospitals and their customers, the physician offices that they work with.
In parallel, here in Spokane, there was a group that formed in 1997 called the Inland Northwest Community Health Information Project or INCHIP. That was a group of physicians and other health care providers, including INHS, that came together to talk about how they could collaborate on health information technology projects. That group has become the guiding body, the governance body for the community projects that have been undertaken.
Last year, that group made a decision to go ahead and take the next step in their evolution and are becoming the Northwest Regional Health Information Organization, the NwRHIO.
The INCHIP has really been filling the governance role. In some ways it is an informal governance role, unlike some of the other RHIOs that are being established around the country. The INCHIP has been serving as advisory and in some cases decision-making body on community-wide standards and processes.
So, for example, on a decision-making standpoint they made the decision many years ago that they were going to standardize -- as the way to move data electronically. On an advisory standpoint, they put together a short list of electronic medical records that they would recommend to physician offices in the community because they recognized that the shorter the list of EMRs, the easier it was going to be to establish the interfaces between different organizations.
So, it is those kinds of activities. They have put together a prioritization list for community-wide projects and a community -- index, which we will talk about more, as one of their high priorities. It is a voluntary coalition. Members get together monthly. A lot of it is collegial discussion between one physician or laboratory and another. What are you doing? What are we doing? How can we do it better together?
There is a formal governance group and they really function as the guidance body for the community. Now, it is possible that as we evolve toward a more formal RHIO, that this governance board is going to be modified or a new board that reflects more of a RHIO membership. But because the -- northwest has got INHS, because we have already got the technology infrastructure established for a lot of information exchange. What we are really focused on with the RHIO is more at a policy level for governance. So, again, we are a little bit different that way than other parts of the country.
This is just a short list of the members of the northwest RHIO, the formal members, which includes INHS. I mentioned Pathology Associates Medical Lab. It is a large regional laboratory that is based here in Spokane. Inland Imaging is a large imaging reference center also based here in Spokane.
The Community Health Association of Spokane is a federally funded safety net provider, a number of clinics in the region and so on down the list to some private clinic systems. The public health agencies here in Spokane and also in Coeur D'Alene, Idaho with that having the whole sisters, they are right across the border from us and many, many physician offices and clinics.
Now, you should be able to supply this title, INHS MPI. The master patient index issue is really twofold. First, I am going to talk about how it works inside the INHS system. We have a single hospital information system that we are operating in all of our participating hospitals and that happens to be one made by a vendor called Meditech. In all of those hospitals, there are approved personnel, who can add new patients to the system. They use a fairly standard algorithm-based query process.
So, they can go in if they have a patient who shows up in their hospitals, they can check and see whether that patient exists in the system and it is not just whether they exist in that hospital's prior record, but it is whether they exist in any of those 34 hospitals. So, that query process is something that is, I think, fairly typical. It is looking at a combination of identifiers, including social security. I heard Susan mention that that is becoming more and more problematic and that is certainly the case for us as well.
If there is no match whatsoever, then as the hospital is allowed to enter a new patient and a Meditech master patient is assigned -- index is assigned, if there is a match if it is an absolute exact match and there is no question that it is an exact match, then the existing master patient index is returned to that hospital and they put that into their medical record for that patient.
So, the Meditech master patient index is used by all the facilities on the network. These facilities still have developed individual medical record number and that is what they use for all their internal tracking. In fact, that is really all they see. The system-wide master patient index is invisible to them. But it is used to link records across the system.
As to what that means is if a patient shows up at the ER in Spokane and a physician needs to find out where else they have been treated, they can look back and they can find records from a year ago or two years ago, where the patient was also treated at a hospital in Othello, which is 200 miles west of us. They have access then to all of those prior hospital records. All that is done based on the existence of an occupation index throughout the system.
Now, I mentioned that we have 34 hospitals currently on the system. Two of those are just in the process of joining and our network has grown. We started in 1994 with about six hospitals and we have been adding hospitals each year as they have become aware of the model and are looking for a more cost effective way to manage their health information.
So, it is fairly routine for us to add new facilities. When we do, we use a batch process to compare our records to those in the hospital system to see if there is any overlap. As I said because we are a regional referral center, then that has been fairly common because there is a lot of movement between hospitals and the system.
As we add more and more hospitals outside of our region, that is going to become much less common. But that prematch is run on a batch basis and, again, with the querying process, if the match is exact, if there is no question, then they go ahead and link the existing medical record number to the existing master patient index. If it is not exact, then the facility has to go through an add process, just as I described before when they are adding a new patient.
It is not just hospitals that we map records to. I mentioned the Pathology Associates Medical Laboratory. Over several years, we have gone through a process of matching our master patient index, our records to their records. We used a similar process to that one I just described for the new hospital.
OAML, Oncology Associates Medical Laboratory, partly covers the same region we do, but they have more broad coverage. They actually provide laboratory services across about a seven or eight state area. So, we don't get a huge amount of matching with them. It is more on the order of 40 or 50 percent where we find that we have got the same patients that they do. But we do that periodically to catch up and make sure that where it is possible to match the patient, we can move the data based on that.
For another organization, we established a real time query process and that has been a little bit more arduous to work out. So, that was for the imaging center, where we set up a process where they can -- a person at the imaging center can actually query the system and see whether the patient exists. That is built on the HL7 transactions for an eMPI query. So, that allows them real time. If the patient is standing there and they are trying to get registered, they find out if their patient already is -- it is an operator-based decision. Meditech doesn't make the decision for them but it gives them enough information to make some kind of a conclusion on whether it is a true match.
Just some matching issues, some things to be aware that we have learned in matching between organizations because we are often matching between disparate systems, as I just described. We do require, as I think Susan described very, very well, a variety of data elements in order to match, for example, date of birth, sex and social security number. Realistically, many organizations don't have all this information, especially laboratories. Laboratories are much more likely to simply have some kind of a medical record number that they have got from the ordering facility, whether it was a hospital or a physician office and they may not even have a patient name.
Their customer is first the group that ordered the test and as long as they have got that identification, they don't need anything else or at least they haven't historically for laboratory testing purposes. But as we are moving into this age of electronic data sharing, they are going to need that information. So, it is going to become more and more of an issue on who has what data so they can do the matching.
The other thing we have become aware of in matching is the issue of duplicate records and the bigger your data sharing process gets, the more you are going to be bringing in organizations that may or may not have a lot of experience in managing their data and may or may not be creating a lot of duplicate records. It is one thing to be working with group health cooperatives, where they have got a very sophisticated ability to manage the health information. It is another to be working with a ten doc clinic here that may or may not have that level of sophistication.
So, you have to recognize that when you are sharing data and you are starting to develop a multi-organizational system of sharing data that the weaknesses of what can proliferate amongst the weaknesses across the system. So, if there are problems in how data in one system is managed, if you are not careful at the get-go, then that can proliferate throughout the system.
The next slide, which brings me to the question of the moment of the enterprise master patient index in RHIOs and how that is going to function, how it is functioning there now and what we indicated at least for our future. There is no question that identification of the patient is the critical success factor in a RHIO. The whole purpose of a RHIO is electronic record exchange and if you cannot identify the patient, if you can't make sure that you have got the right person before you send that data off or before you, heaven forbid, merge records if you are not sure who the person is, then you cannot run a RHIO.
So, it is very, very important that the MPI issues be worked out up front and then you make sure that you have got standardized processes for identification in place. It is also very important to recognize, as I said before, that one organization's recordkeeping decisions and processes are going to impact everybody else. So, you have to have agreement on those up front.
But where we are here in our region and I think that is fairly typical is that every organization, whether it is a one physician office or it is a ten hospital network has got some kind of a medical record number for tracking their own patients. Then there are two options really at the community or the regional level. We can try to get everybody to agree to use a single identifier and just change their medical record number to whatever everybody has agreed to or you can take the mapping approach and map the organizations, medical record number to some kind of a single community identifier.
As I described, that is really the approach that we are taking here. So, what we are looking at as part of the northwest RHIO is a joint purchase, some kind of a commercial product and I understand you have heard from some of the vendors about their products in the past. But that product would assign a community MPI and then link that to their institutional medical record number.
The difference between that and what we are doing now is that we are doing it pretty much in a case by case basis. So, INHS has got an application index. If we want to link up with a laboratory, we work with the labs and we match up and we realize -- identify the common patients and assign a common number. But we recognize that as this thing grows, as the northwest RHIO grows, that we are going to run into real scalability issues.
We can't realistically on a case by case basis do that for every clinic that has got a different EMR system or do that for every national laboratory that wants to run data through our system and so forth. We need a more formalized approach and a more efficient approach to assigning an MPI. That is why we are looking at these commercial products.
Interestingly, as we have talked to the vendors, the RHIOs are a new issue for them. I mean, their whole experience to date has been single facilities, a hospital or other organizations or wholly owned networks. So, if there is a hospital organization that might have ten facilities across the country and they want to run a common MPI, that is a model that the vendors are used to because they know how to -- they ask how many medical records do you have, how many patients do you have and they can figure out how much to charge.
But the RHIO model is very, very different because you have got multiple organizations in many cases treating the same patient. So, you have got a patient who shows up at the imaging center and also at the lab and also in the primary care provider's office and in two specialists and at two hospitals. Can you tell us for each time that patient gets -- based on the number of patients in the region? It is a major question and we have interesting conversations with the vendors about how they want to handle this.
We don't have an answer yet. The other piece, of course, is scalability. RHIOs are a moving target. From day to day it seems like the concept is changing. Are we talking of communities? Are we talking a region, a state, multi-states? So, how do you define some kind of enterprise master patient index process when your final scale is completely unknown. How do you assure scalability when you might be working with five million records or twenty million records.
So, those are some of the things we have encountered as we have begun to look into and decide how this region is going to handle the enterprise master patient index. This is a few summary comments before we open up for questions. I understand that one of the things that you are revisiting is this issue of a national patient identifier and would a unique patient identifier simplify information exchange. There is no question. It would be wonderful. Even though we are a community that already has done a lot with data sharing, when our community put in a RHIO response to the request for information that was out a little bit over a year ago from our kit and we strongly recommended that a national patient identifier would be a terrific idea for health care.
On the other hand, is a unique patient identifier absolutely necessary for a RHIO to do data exchange and we also agree the answer is no. We are doing it now. It is possible to do without a unique patient identifier. It is harder. It may be more problematic, although the vendors will tell you that the matching algorithms are good enough where it is not a -- it is not anymore problematic than having unique identifiers, but there are certainly a lot more policy and -- issues to work out without that unique identifier.
In terms of using a master patient index in RHIOs, there are, as I said, a lot of things you have got to decide on up front. You have to agree on how you are going to identify. If you are going with an algorithm-based approach, you have to agree on what that is, what elements are you going to use, when are you going to identify a patient in the health care process, what are you going to be using for matching and how rigorous is your matching criteria going to be and what are you going to do when they don't match. How are you going to manage duplicates and how are you going to deal with duplicates that have proliferated throughout the system? And is there going to be -- I didn't put it on the slides -- what do you do with unmerging if you have realized there was error in the matching process and so on?
We do have to have some kind of tools for querying and for assigning an MPI across all of these systems and most important you have to have trust. Susan talked quite a bit about the trust that the committee, the patients have to have, but there is also as you get into developing a health information exchange between organizations that are completely unaffiliated with each other, then you have to have a great deal of trust in each other and that they are not going to mess up your data and cause problems for you and your patients.
Which brings me to my last slide, which is a little personal experience I have recently had with matching gone bad, not in the health care fortunately, just a much smaller problem with my credit history, but I found it fascinating because I had just been working through this whole issue of matching patients and I found out accidentally that my credit records have been merged with someone else's by the credit reporting agencies.
As I studied it, I realized that the credit industry must have matched my record with this other person's, who happened to have been my father-in-law on very, very few data elements. They must have matched only on last names, which was the same spelling, a similar sounding first name -- my name is Jac, which throws people, but it is -- my father-in-law is the same, although he spells it differently. The address, at one point we lived in the same house when my husband and I were first married and we lived with his parents for a few months.
That is what we had in common. What we didn't have in common was gender, social security number and most importantly from my perspective mortality status because my father-in-law, unfortunately, is dead. The reason I found out about the whole issue was that I was denied a credit card because they said I was deceased.
So, I was fascinated by the fact that this industry, at least, the credit industry doesn't appear to have taken the issue of matching and identification very seriously and doesn't have any problem merging records, even when there is very, very little evidence that one person is the same as another. It gave me much more appreciation for the health care industry and its efforts to do it right, also recognizing that if the health care record is inappropriately merged, the consequences can be much, much more serious.
So, as I said, I commend your committee and your efforts to make sure that health care is doing it right and with that, I just would like to open it up for any questions.
DR. WARREN: I am glad the committee enjoyed the story. When Jac and I were talking on the phone getting ready for testimony, she shared this with me and I said you have got to put that on the last slide because I thought it really grounded us with the dialogue that we were going to have.
So, with that, Susan, if we could have you come back up to one of the microphones.
DR. STEINDEL: Judy, while Susan is coming up, I would like to comment. I actually related to her comment about her -- was it your mother-in-law lying? Because my mother did it until she was in her seventies and we found out about it.
DR. WARREN: I was going to say probably we all have mothers that have done that because I was telling Maria my mother has also lied about her age, but she always tell the truth about the year she was born. So, we have not gotten into these troubles but we have never really known how old she was.
Okay. First question, Jeff?
MR. BLAIR: Thank you, Jac. Thank you, Susan. Very grateful for your coming and testifying on your to some degree pioneering experience with trying to pull together some form of an emerging RHIO and trying to grapple with the idea of matching patients to their records. Clearly, it is one where there is not a lot of good paths and you had to find your way to what works.
We have had a number of other testifiers. Most of the others have been health information exchanges and most have, in fact, indicated they have used a probablistic approach and that, you know, the key identifiers were the name, the social security number and the date of birth. So, all of those things are similar and they also indicated that the social security number was the most reliable, the key identifier.
The question that I have a little bit is your pathway and the things, the problems, impediments that you have encountered as you have come to the conclusions that you have come to, since you have chosen the probablistic approach, did you encounter -- well, let me just zero in on two specific questions. I will just do that and then let other people ask questions and then if there is time, I will come back on some more.
No. 1, with the probablistic approach you have to strike a balance and from other testifiers, they have said that they could have a higher percentage of matches if they would tolerate false positives. But if they do, they run legal risks, patient safety risks. The other testifiers have indicated that they have been gravitating towards coming up with algorithms that will be zero false matches, even though it means that the percentage of matches is higher and the work load is higher.
So, I would like to know if you have developed policies that are similar. The second question -- there are two questions. That is one. The second question is even though this is only matching patients to records, when you have gone around to health care providers and health plans and clinics, have some of them said I am not going to play because of my concern about your having some degree of access to the records that I have and I consider them either an asset or a competitive advantage or that there is a privacy issue and if you have, what have you said or done to get them to cooperate? Those are the two questions. If both of you could address those.
MS. DAVIES: Susan, why don't you go first since you are there in the room.
DR. MC BRIDE: Okay. I think probably that second question is a little bit more for you, Jac, since you are linking the labs and the pharmacies and the physicians and we have begun to talk amongst each other, but we haven't actually done that piece yet. Ours is primarily with our hospital sector that we are working with right now. I think one of the things you have to -- people talk about the use case, I think, with previous testimony and why are you linking? What is the purpose of the probablistic linking? Of course, in Jac's case, it is definitely to deliver clinical care, which is the direction we are headed in in the future.
What we are doing with it now, though, is to address patient safety and quality to look at health services research questions and they are very specific isolated questions on the health research side. So, we work with the researchers to decide the sensitivity, specificity issue and, you know, whether or not to manipulate in that fashion. So, it is really sort of a different use case and I think the probablistic linking for those purposes is adequate. It is good enough, but on the other hand as Jac talked about are issues with clinical care and this is what our CIOs, our chief information officers in the region have said, that is not going to be sufficient when we start moving into the clinical arena, we don't think.
Some of those very issues that Jac described, we have a 15 hospital system. We have a 13 hospital system. We have HCA and Tenant(?) in our area. So, I think that as we begin to look at how we are going to address this regionally, we are hearing our CIOs tell us we have to move forward the master patient index of some sort. We need to figure these problems out and that is going to be our first step.
We are not going to link -- use other methods. We want to figure this out first. So, right now, the trust piece that Jac spoke to as far as the government model and that is why we really were enamored with the Visa story because he established that trust component of partners that would have them all be willing to share data, which I think was Mr. Blair's second question. We think that it is in the governance structure, which Jac sounds like she has got a beautiful governance structure out there that probably has addressed a lot of what -- and we are still going to have those players that may say exactly what Mr. Blair said. So, I think we are going to have to do it as a committed community.
What we recognize -- there is a lot of momentum in our region, as it appears there is in Jac's, where providers are saying now we have got to work together and hospitals have been doing it for some time. But the physician community is equally as committed now and our politicians in the area are interested, our county commissioners, our uninsured rights. That is the pain we are getting hit with. We have 24.6 percent of our state that is uninsured right now. How are we going to deal with that?
How are we going to manage the health of those populations and we haven't seen the Rita/Katrina effect that Texas is going to get hit with the uninsured that came in from that episode. So, those are -- I think that is how I would answer it. I will hush now and let Jac respond.
MS. DAVIES: Okay. Thank you, Susan.
On your first question, Jeff, the issue of is a probablistic approach good enough, definitely we are being very conservative about when we declare our max and we are going to make a decision to merge records. At one discussion we had an extensive discussion about that. The group agreed that duplicates, when you are talking about a personal health record, duplicates are less harmful than a bad merge. The reason for that, particularly from a RHIO perspective is that if you have got John Smith identified under -- at three different facilities, a different MPI associated with those, so you have gotten duplicates, when somebody does a query to see those medical, they may get three John Smiths, who are all the same person, but from a health care perspective, that doesn't matter so much because they have got all the records.
They may have to sort through them a little more than they would if they were merged, but at least they are all going to be there. On the other hand, if the records are merged in a bad way, then that could very much affect health care. So, we have been conservative about the decisions to identify a person and to merge the records. We feel it is not from a health information exchange standpoint, duplicates are less harmful and that can be dealt with more easily than a bad merge.
On your second question, has anybody --
MS. BLAIR: One piece on that. One first question was really related to will you tolerate or accept a false positive, two different records that appear to be the same person, but are really not?
MS. DAVIES: Well, no. I think we are being conservative on that as well. So, that is why I said that we tend to not make a decision that it is the same person, unless there is very, very strong evidence that it is.
MR. BLAIR: Thank you.
MS. DAVIES: Okay. Then has anyone said no? One of the great things about this region is that they have been working at this long enough where for the most part both the large organization, the hospitals, the labs and so on and certainly those physicians are well past the point of regarding data as an asset. I know that is not the case in all communities, but one of the great things about the INCHIP, that governance group I mentioned, is I heard from a physician, who was a founder, that they made a decision from get-go that they needed to treat information as a public good and it needed to be treated in a way that would serve the best interests of the patient, not as a way for each organization to achieve some kind of dominance over the other ones.
So, just culturally, it is a good place to start and then sort of how have they, even those who don't have electronic medical record systems and so on -- or they are surrounded by those who do and who are touting the successes and the way most of them are treating these electronic transactions is as an extension of the paper exchange that goes on all the time and, again, remembering, of course, that health information exchange happens everyday. It just happens on paper.
So, philosophically, when you send the file electronically versus having a courier carry it over to the office, you are doing the same thing. So, I think that is the attitude that most of our providers have taken so they don't see this as a threat or anything that is going to be different than their current practice.
DR. WARREN: Harry, you had a question?
MR. REYNOLDS: Thanks to both of you, outstanding job.
The question I have is both of you alluded to a standard minimum data set that might be used in whichever method that you select. The other thing is both of you mentioned the social security number as the identity theft laws roar across the country right now. How are you dealing with that? I mean, I think, Susan you alluded to it that some people won't give it up and more and more state laws are going to penetrate how you actually do business and whether you can or can't even have it.
If both of you could talk about the minimum data set and then the social security number, I would appreciate it.
DR. MC BRIDE: This has been a big challenge and I think, you know, some of it is educating both the legislators, as well as the general public about our independencies right now and the fact that we are diligent around protected health information and that is what HIPAA was all about. HIPAA was about trying to get safe transactions as private health information and if you can convey that -- and they know about HIPAA. You know, they experience it enough now after our anniversary, where -- the public know about that. So, that so far -- we even have one of our major systems that put together an educational script that they are going to share with the rest of the hospitals around how do you educate the public about these issues.
Likewise, I think, you know, the consumer groups that are beginning to express concerns, but I think we equally need to say we are dependent on it now and we are trying to solve this problem because I don't think it is our long term solution for us to be dependent on the social security number, but it is working for us right now and if we didn't have it, we could not do as effective surveillance. We couldn't do as effective work with our public health departments, the health services research activity that we are doing and the linkages that we are doing. We couldn't do it, not nearly as effectively.
So, I think those are our challenges if we have to need to move away from or will be forced to move away from it.
MS. DAVIES: I think that the impact of having increased concern about the social security number is just less and less reliable matching and increased reliance on other data elements, address being one possibility, that, you know, the -- going through the name matching process as much as possible. So, the net effect is going to be less reliable matching and probably a greater number of duplicates formed in the system.
I think that we as a health care industry can talk all we want about all that we are doing to protect our records and anything we say is defeated by the article -- the individual incidents, like the health records that were in somebody's car and the computer was stolen in Oregon recently or the University of Washington, having somebody hack into their medical record system.
Those get far more press and far more attention from the public than anything that we say. So, if we can, as the vendors say, rely more on a complex -- a range of data element and not just the social security number, we are probably better off. But, frankly, I don't know and don't have enough experience to know how valid the claims are that we can rely on a dozen different data elements and get just as good a matching.
MR. REYNOLDS: So, do you think a minimum data set is a dozen or do you think it is three or five or six or --
DR. MC BRIDE: That is one of the things we are looking at in the State of Texas right now with our new health information technology advisory committee is what do we think the minimum data set should be. I think one of your discussions talked about hierarchy and at the clinical level that Jac is talking about you need tremendous detail, but then at the regional level does there need to be less detail for you to -- and that whole idea is one that we are definitely looking at and, you know, it is always better to have multiple people working on what the issue -- and I think, you know, we are sort of waiting on the national standard and we are going to look at it as the recommendations come down on what the minimum data set -- we have some ideas that -- and we have clinicians that have said what they believe needs to be the minimum data set.
Clinicians will tell you, you know, the more information we can have the better, but then digesting that information is challenging. So, I think electronic digesting of the information is actually very -- really different than if you are flipping through a paper-based record and those will be our next challenges, once we get all this.
MS. DAVIES: Well, as I just think about that, I don't know what the number is, but I have a public health background and my reaction to that is it is like a disease investigation or making a decision about a public health intervention. You are balancing the risks and benefits. So, there needs to be enough guidance as organizations are trying to make decisions on a master patient index or a matching process. There needs to be enough guidance to know that three elements are too risky and twelve elements is so conservative, it is going to take you two hours to do a match or whatever. You need to -- your benefits of that are that you have reduced your false positives or your false negatives down to x percent.
So, that kind of guidance on what are the risks of a certain matching algorithm and what are the benefits of it so that organizations can make those decisions would be extremely helpful.
DR. MC BRIDE: I may have misunderstood your question, Mr. Reynolds. Were you actually talking about a minimum data set for matching or minimum data set for sharing of information? Which were you speaking to?
MR. REYNOLDS: The matching.
DR. MC BRIDE: The matching. Oh, yes. Okay. Well, we have settled on the characteristics that you saw, you know, the name, the address, but depending on what the issue is and what you are matching and how long across your matching -- you know, people move around and so there are challenges with even the minimum data set and you saw what our minimum is, right now. I think as the issues such as, okay, now you don't have social security number, you are going to have to -- as Jac said, you are going to have to extend that data set because that is what is getting us the most discrimination right now. So, if we were to eliminate that or not have it or we begin to get more 99999s in our data, we are going to have to depend on other methods for linking and more data.
MR. REYNOLDS: Thank you very much. Thanks to both of you.
DR. WARREN: Simon.
DR. COHN: This is just sort of an odd question that I am sort of curious. This one is going to maybe be a little too far beyond but, obviously, I think we are all talking about this issue of a data set as opposed to a single element and I think can think to over the years hearing stories of, in fact, social security number, certainly, alone isn't all that good either.
Obviously, with the issues relating to people using social security numbers will be confirmed with this other issue. You know, it is becoming obviously increasingly common, though it is not universal, that people are paying with credit cards for services related to health care. If you are D. Hocking(?) conversation and all that, is there something to be investigated around actually using credit card numbers as part of matching algorithms? I mean, is there a -- I am just trying to think of the terrible downside to that and I know it isn't as -- I mean, people don't necessarily hold a credit card for 30, 40 years or whatever, but, of course, as one of a number of items, have you thought about that, looked at that? Is that a -- is that so weird as to you won't even mention it when you go back to Texas or --
DR. MC BRIDE: Well, we do have people paying with credit cards and I think we are going to see more and more of that because of the different health plans that we have got employers dealing with their StopGap and we do have absolutely they are putting them on credit cards. What I guess I see with the D. Hock and Visa story is that there is a model there. There is a model of how they establish trust, electronic exchange of data because that is basically -- they started out with this world view of we are the banking industry. We are a bank. And what he realized is, no, we are not a bank. We are moving data around.
So, I think we need to use those types of scenarios, their story, and see what fits and what doesn't. But the unique ID that is on that credit card number, I think, is what is a very powerful component of that story and then how did they get people to trust enough to deposit that and then the security and privacy around it all, the exchange of that information or the mainly -- and this is very early pursuit of looking at that. I mean, within the last week we started kind of looking -- investigating this and we have been thinking about it for some time, but hadn't actually talked to the gentleman until recently.
MS. DAVIES: Well, I have to say my recent personal experience with the credit industry doesn't make me a little excited about that process, but I think you are right, that we are going to have to be more creative about other data elements that could realistically be used in a matching algorithm and I see no reason why credit card numbers could not. I think you might run into some of the same issues about public sensitivities that you are running into over social security numbers, wanting to know why do you need my credit card number or the concern about misuse of that information is likely to bubble up as well. But it certainly is something that is worth investigating.
DR. WARREN: We are running close to time. So, I have two more questions.
Stan and then Robert.
DR. HUFF: So, one of the things that occurs is if you speculate about the possibility of making unique identifiers for purposes of identifying people connecting records, all of the things that we have talked about, one of the issues is obviously the cost of producing that number. One of the things that would be interesting, do you have any idea how you could or if you could put a value on having that number in terms of the process of the system, decreased waiting times for patients, the fact that you don't have to do the matching or at least in a big percentage of the cases you don't have to, the fact that you may have to have backup situations, but if people bring their card or brought their number, how much it would expedite their care and the accuracy of their care.
That would in some sense be an offset to the cost of creating that number. Any thoughts -- would there be a way that you could put some monetary value on having such a number available?
DR. MC BRIDE: Well, I think -- and, Jac, you may be able to speak to sort of the before and after picture of your entity, although it sounds like you have some inefficiencies in the probablistic linking that a unique number would help create efficiencies around what even you are doing in the northwest. But I think one of the interesting things that Mr. Hock said, they have been looking at this and so they really -- they have been working with some organizations and a physician group and they have done some cost benefit analysis and what his comment was that the savings were potentially huge. So, we are going to be exploring that. What would that look like? Where would it shave and has anybody done any cost benefit analysis around that unique ID and I think quite frankly in the DFW area, we are very early in that stage of looking at that, but you can only imagine the inefficiencies built in how a patient -- or you or your family has gone through a health care system recently and how many times have you given your health history recently. Even the workforce time that it takes to do that, if you think in terms of man hours that we are losing in the health care system just from answering your health history, you know, that, compounded by millions of people, you could only fathom what the savings might be.
But we have got to do it well, too. Otherwise, we are going to create inefficiencies that are going to have things happen that we don't want to happen.
MS. DAVIES: I think that if you are looking at trying to cost out the difference between having a national patient identifier and not having to rely instead on matching. You need to be able to tease out what costs and what savings are specifically associated with the identification process.
We have not done that. We certainly have a lot of information on how much it costs us to do a matching batch match against the new hospital, the Joy Saar(?) Network, or to establish the query process. You know, so we have that kind of information and I guess you would make the assumption is that for the most part all of those activities would go away if you had a national patient identifier to be replaced by some much simplified -- someone would give you one number and you would run that against your database and maybe a little bit of backup information just to verify.
We have not done it. As I have said, it certainly seems possible and it may be worthwhile to support the argument for a national patient identifier. I have to say my personal feeling is that the sensitivity on that issue is so high that even if you could demonstrate millions or more savings across the health system by being able to do away with the matching process, that that wouldn't be enough to make it worthwhile for the public.
MR. REYNOLDS: I had a second question, a comment there.
You may be gauging the public correctly, but do you -- I guess, is there actual fact behind that. Is there a rational reason why having a national identifier actually makes me less private and less secure?
MS. DAVIES: No, but that is speaking as somebody who is reasonably knowledgeable about the health system and about how information technology works. As I said earlier, I think that there is a great deal of emotion and that you get a -- the public hears a lot more and responds a lot more to the press articles about when bad things happen, when there is a hacker or when there are records that are stolen and so forth than they do to all the assurances that we can make.
DR. HUFF: I agree. It is a question of perception, but it would seem, too, that if there is really no basis, then you should be able to overcome that hesitancy. My question is is there a real risk there or is it just a perceived risk?
MS. DAVIES: I do not believe there is a real risk. I do not believe that there is any greater risk of exposure for a person's health information if they had a single identifier than if they don't. I don't know how you convince the public of that.
DR. HUFF: Second question. If you were to make a unique national identifier for patients, what would be the ideal characteristics of that identifier?
MS. DAVIES: Tell me what you mean by that.
DR. HUFF: What would be the characteristics that would allow you to get one? How would the initial assignment of the number happen? Should it be a nonsense identifier or should it imbed some kind of information in a number? Should it have a check digit?
MS. DAVIES: I am sorry. I really don't know enough about the options, I think, to be able to answer that in a way that is going to be helpful to you.
DR. MC BRIDE: I think that whole area is, you know, really mathematically based. I have worked with enough programmers to know that alpha numerics and the number of fields and how many times you will have to, you know, filter through the data and all of that, there is a real science around that from a data processing standpoint. I would bet the credit card industry -- you know, some of it has to do with a volume of people you are going to be putting through it and the credit card industry has gone worldwide in their numeric values and they are frequently alpha numeric. I guess what I envisioned was an alpha numeric that would have quite a few digits associated with it, how it is assigned and the whole process that takes place.
I hadn't really thought through that.
MS. DAVIES: One comment, though, that has not yet come up is the whole issue of biometrics and I know that a very, very primitive level, I heard a story the other day about -- actually it is here in town, Gonzaga University is experimenting with a system where students use a thumbprint to get access to food services and so on. It may be that a biometric approach would be more -- they would probably be more comfortable with it because it is not something that can be stolen or imitated so readily and the technology may be getting to a point where it is financially realistic.
So, just a thought about an approach here would be to not rule that out.
MR. REYNOLDS: Okay. Thank you to both of you, excellent, excellent job. Great information.
We are going to take -- let's get back at 3:20. That is about a 12 minute break so we can continue because we have got two more presenters and we want to make sure that we stay on time.
So, thank you very much.
[Brief recess.]
DR. WARREN: The next presenter is David Espey, who is going to talk to us about some of the issues the Indian Health Service has about data linkages.
DR. ESPEY: Thanks for the opportunity. We listened to the last 20 minutes or so of the previous presenters. I focused on some issues that we think might be more relevant to this discussion.
Most of the linkage activities that we do are for the purpose of data for the improvement for epidemiologic purposes. So, with that in mind, we will just go ahead and proceed. Both Melissa and I are Indians from the CDC to the Indian Health Service, from the Cancer Division of CDC.
The two main linkage activities that we are involved in are between the Indian Health Patient Registration Data and State Death Records and central cancer registries across the United States. Those are records in both major systems of cancer registries, one supported by the National Cancer Institute called the SEER Registries that some of you may be familiar with and the other one is the CDC supported system of cancer registries called the National System of Cancer Registries.
We will focus on the -- at least for now on the death record linkages. This is very -- and there are really two steps and we link records from state vital statistics or cancer registries with the Indian Health Service Patient Registration Database. That database includes individuals who have had some sort of services provided by the Indian Health Service within the time frame starting in the mid-1980s when various service units in the Indian Health Service began using electronic patient medical records.
Is there anyone from around the mid-eighties, who has served within the IHS or paid by IHS contract -- is in the patient registration database and it is approximately 2.4 million records. There is a lot of duplication. We unduplicated only at the level -- if someone has a complete match across security, first name, last name, date of birth and gender. Then they will be eliminated. Otherwise if there is any discrepancy in any of those fields, they are maintained in our registration database just because we assume those errors could be duplicated elsewhere.
Then the purpose of our linkages are to identify records and these databases, either vital stats or cancer registries, who have been misidentified or misclassified as non-native. Then the final sort of use -- for us to use these improved data report -- mortality patterns and cancer burden of American Indians and Alaska Natives.
-- watching the slide show that we sent?
MS. FRIEDMAN: Yes. If you could please tell me when you are ready for the next slide.
DR. ESPEY: The fourth slide is linkage process. Basically, we went through a procedure where we drafted a proposal and had a lot of interaction with the states and agencies representing state vital stats registry, state cancer registries.
We had research determinations both at CDC and the Indian Health Service with the recommendation that this is really a data -- improvement -- not a research activity. We elaborated plans for data management, the linkage algorithms and an analysis plan.
New slide, data management. With each state and each registry, some registries are run by the states and some registries are run by non-state entities, like a university or a private contract, by a contractor. We had memorandums of agreement, memoranda of agreement and data use agreements to allow us to exchange data with the state and in most instances, the data for the linkages were sent from the state to us by FedEx in an encrypted format to our office in Albuquerque.
We then -- the linkages and then sent the match results, which we call Match File 3 and I will show you a graphic of that in a moment, which contained both the Indian Health Service, the state's record of the match pairs that we felt were indeed matches. So, they could make the determination on their own if they wished to review them to see that it was indeed the same individual and then from that create analysis files.
This one is entitled "LinkPlus." Basically, we use a probablistic algorithm and we use a public use software that was developed at CDC called LinkPlus, which is available on the Internet at the web site at the bottom of the page. I don't know how much of the detail that -- I am sure you are familiar with probablistic linkages and we use a system of blocking variables to increase efficiency, whereby only records with matching key variables, identifying variables are compared and it greatly speeds up the matching process.
The next slide, it is called "Matching Variables." So, these are the variables that we use for both the death record linkages and the cancer registry linkages, social security number, date of birth, last and first name, date of death, middle name, which is usually supplied as an initial and gender.
An example here using Melissa, my colleague Melissa, as the example. The first pair -- the fourth and fifth columns are the date of birth and social security number. You can see that there is just a slight discrepancy in the first name, but otherwise it is a perfect match. The program, the algorithm generates a score for potential matches and she would clearly be what we would consider a perfect or near perfect match. Then there is a whole other group of potential matches called clerical reviews that are sort of the gray areas, which require an individual review. What we do for clerical reviews is we have two independent reviews of the group of these clerical reviews and then we adjudicate them as to the discrepancies between the individual reviewers.
So, for instance, in that second -- if somebody felt it was a match and someone else -- and the second reviewer felt that it wasn't a match, they would actually have to sit down and discuss it and maybe look for additional sources of information from maybe the social security index web site or something like that to make a decision.
This is just a screen capture of LinkPlus, which is a CDC public use software and it is divided into sections to determine the blocking variables, the matching variables and putting in the values for missing -- missing values for a given variable.
The next slide, "Data Flow," this really is just in summary, either the registry or the vital stats office and we link it -- we generate two files. One is what we call Match File 1, which is a perfect or near perfect matches. Match File 2 are the clerical reviews, which get, again, adjudicated independently by two reviewers and then any discrepancies between the two reviewers are further discussed and oftentimes a third person will make a decision and we tend to err on the conservative side. If we can't feel comfortable -- and there is always a subjective element to this part of the algorithm.
If we don't feel comfortable that a person is a match, we don't call them a match, even though there is a pretty good chance they are a match. Then those two groups of records are combined into a Match File 3, which is sent to the registry of the vital stats office. We encourage the state officials to review the records. Some do and some don't and then after they do that, to delete the Indian Health Service records that we send back to them.
The next slide, these are just the regional breakdown that we use. There aren't that many Native Americans and Alaska Natives and to have reasonably stable estimates, we grouped fairly broad -- we grouped the states in fairly broad regions to have -- for stability of estimates.
The next slide, these are just the results from -- and this is the cancer registry and these bars, you can see that the green part of the bar, they are individual registries in the states. The green section are those that were identified as Native Americans prior to the linkage and the red sections of the bar are those that were added as a consequence of the linkage.
Again, our database is defined by the individuals being Native Americans, based on their eligibility for IHS services, a tribal code and there is an additional field called quantum, which is the degree of native ancestry. So, between those three fields, the records and the IHS patient registration database represent Native Americans.
The next slide is a very similar graph or bar chart for vital stats linkage results that the discrepancy results aren't as impressive as they are for cancer registries, but they is still a substantial amount of racial -- in vital stat databases.
This parenthetically has been confirmed by linkages between the census data and the National Center for Health Statistics, National Death Index where health is self-identified in terms of their race, compared to the race as identified by -- at best, there was a large discrepancy between the two in the order to 30 to 40 percent for Native Americans. So, in other words, a person who is self-identified, said I am a Native American, when they died and the information was gathered by the funeral home either by asking the question or assuming based on the appearance of the person who was deceased made a judgment and there was up to 30 to 40 percent error rate between the two ways of collecting race information.
There are other linkage activities with IHS. We didn't have a lot of time to gather information about this, but very quickly, one is a routine or quarterly linkage with the social security administration and that is to verify the accuracy of social security numbers and IHS. The second one is with CMS and that is to -- I believe it is used primarily by CMS to track service provided Native Americans and this is one of the easiest ways for them to correctly identify those individuals as to link through the Indian Health Service. Then there is an annual linkage with census and I think the census also uses the data in relation to its being a race-based -- essentially a race-based database, but I don't know that much about the census linkage.
So, that is sort of very brief overview of our linkage activities and we will be happy to -- Melissa and I will be happy to answer any questions that the committee has.
DR. WARREN: Since David is dialing in, he is requested that he has another meeting. So, could we ask questions now about David's so that he can then leave.
Jeff.
MR. BLAIR: David, thank you for testifying to us.
Quick questions and then -- first of all, does the patient identifier that you have for the Indian Health Service cover all tribes, Pueblos, the U.S. and its territories or is it just southwest?
DR. ESPEY: It is all across the U.S. The major concentration is Native Americans and Alaska Natives in the southwest, but much, much less east, Oklahoma. But we don't use -- there isn't an IHS-wide patient identifier. The IHS is divided into administrative areas that you have an identifier.
MR. BLAIR: And they are different in different areas?
DR. ESPEY: It is different in different areas, right.
MR. BLAIR: Is it different by Pueblo or tribes?
DR. ESPEY: By area, administrative area.
MR. BLAIR: What do you do when Native Americans, who qualify as being qualified under Indian Health Service, receive health care outside of the system in terms of patient identification, both going in and out? The reason I am saying in and out is you may have inter-marriage, where some folks may be living in the city and then going back for some care on the reservation and you may have other situations, where it is vice versa? What kind of patient identification problems and matching and correlating have you had when people go in and out of the system?
DR. ESPEY: So, if a person is treated outside the system using IHS contract health funds, is that the question or -- there are a number of people who have -- who are eligible for IHS services, who have insurance, their spouse, their employment, who rarely interface with the Indian Health Service.
I am not sure I understood the question.
MR. BLAIR: Okay. Maybe I will be more specific. Let's say you have somebody that has been receiving health services on the reservation and then they head into Albuquerque for some specialized care, in situations like that, do you have difficulty -- what kinds of difficulty, if any, do you have correlating the records, the identity, back and forth between people receiving care with inside IHS and outside?
DR. ESPEY: Well, usually it is in the context of using contract health services that a person will -- is referred to specialty care with the understanding that that will be funded by the Indian Health Service. But there is not a unique identifier that is used. I mean, their name, social security, address and so forth -- but IHS, i.e., that area specific is not used, at least -- I mean, there may be some providers or groups that collect but to my knowledge it is not used as routinely as a -- to manage the -- you know, to track the patient.
MR. BLAIR: It is really not a problem?
DR. ESPEY: No. What does -- if a Sioux from the Northern Plains is in New Mexico and they are not -- the administrative area, which would be either Navajo or Albuquerque area, they can receive IHS services at those facilities but they are not eligible for contract health services. So, that person if they needed specialty care not provided by the Indian Health Service, they would have to return to their area. It would be your Aberdeen area or Billings to get those services or they would be considered indigent and receive them, too, you know, that mechanism.
The identifiers that are used in IHS have been problematic because there is a lot of migration and a lot of duplication so a person may be assigned an ID number in Albuquerque area and receive services also in Navajo area. When I say area, I am referring to these administrative entities.
So, they may receive two different ID numbers and our patient registration base, they will be in there two times unless all of the information was recorded correctly, name, social security number, date of birth.
DR. WARREN: Okay. Thank you, David.
Any other questions for David?
MR. BLAIR: I just have one and this is -- maybe if it is an example. Does the population that you serve, Native Americans, have a very high percentage of names that are identical? Because there are certain racial and ethnic groups where the names are the same. There is going to be a lot of Rodriguezes and Martinez in our area.
So, anyway, I am wondering if you are running into that and if so, do you wind up with an algorithm that has been especially helpful in dealing with that problem?
DR. ESPEY: With frequent names, frequent --
MR. BLAIR: Yes.
DR. ESPEY: Well, in the probablistic algorithm, there is a frequency analysis that if a person has an uncommon name, then a linkage on the name will get a higher score than a linkage or a match on a more common name. But in terms of types of names like algorithms that sort out Hispanic ethnicity, there is nothing like that that we did.
MR. BLAIR: Okay. Thank you.
DR. WARREN: Okay. David, thank you. We appreciate you dialing in twice to talk with us.
DR. ESPEY: No problem. Good luck.
DR. WARREN: Our next testifier is from the VA, Sara Temlitz. With that, Sara, the floor is yours.
MS. TEMLITZ: Thank you and thank you for having me here today. I have really enjoyed listening to the other speakers, as well as learned a lot. So, it has been really interesting to me.
What I have brought today is just really a brief overview of what we are doing within VHA, the Veterans Health Administration, within VA for identity management of patients presently. I will give you a little bit of information about where we are going.
Just to start out, this is how we define identity management. The first definition here is kind of a formal one. It is comprised of a set of business processes and the supporting infrastructure for the creation, maintenance and use of digital identities within a legal and policy context.
Then really how we use it, what it means to us is that we have unique identification for all the patients that we have an interest in within VHA. We really feel that it needs to have a consistent, really robust matching capability. I know we have discussed that a little bit previously and we can talk about that a little bit more. We realize that any matching you are going to have some identity problems and issues that come from that. So, we really need to have some tools and methods and processes in place to be able to deal with those.
Really, essentially, it needs to be able to help us to share this information between the systems that we have to make it effective. So, in VHA, what we are trying to do with identity management, the reason that we have implemented it, is to ensure that we really get the highest quality health care for patients, which means that we have the right data. It is complete. It is accurate and we can get it easily when we need it.
Patient safety issues are a big concern of ours. We do a lot of work to eliminate the potential for those and to also monitor them and to react to them to find out why they are happening so that we can try to be proactive in finding ways to avoid them and also to support initiatives for sharing data, not just between the medical centers that we have within VHA, but also with other agencies within VA and outside organizations, such as SSA and Department of defense and other agencies as well.
Some of the technical specifications of what we have in VHA for identity management, we call our unique identifier an Integration Control Number, so I will use that acronym because we are so used to using acronyms. The ICN is what we call that. We actually call our master patient index, we call it the MPI. That is our enterprise index. It contains all the unique patients with their ICNs and the correlations to the external agencies.
The Veterans Integrated Service Technology Architecture, you might have heard of before, called VistA, is our suite of applications that supports our electronic health record.
MR. REYNOLDS: I am going to step out of line and ask a question.
MS. TEMLITZ: Okay.
MR. REYNOLDS: The reason is I want to make sure I don't miss the hierarchy of these numbers. So, the ICN is the overall number?
MS. TEMLITZ: Yes.
MR. REYNOLDS: Then if somebody is in three different institutions over time, they would have an MPI for each one?
[Multiple discussions.]
MS. TEMLITZ: Here is our obligatory acronym slide here. The DFN is the data file number, which is that internal VistA ID, which is just what you were asking. The station number is actually the unique number that is assigned to each VistA instance. So, if I am seen in a medical center in Milwaukee, they put me into the local database. The station number is 695 for Milwaukee and my DFN is my internal number within that database. So, if I then go to Madison or if I come to Washington, D.C. or wherever and I go to another medical center, I get that same -- I get a new unique combination of DFN and station number as my internal number from the source system is what we call it concatenated with that station number.
Those combinations of DFN and station number are what become the correlations. So, each of the sites that I am seen on, those are all correlated underneath the integration control number. So, that becomes our overarching number.
Does that help a little bit?
MR. REYNOLDS: But where did MPI come in?
MS. TEMLITZ: The MPI is the structured -- the database, the index that holds all those numbers in the correlations --
MR. REYNOLDS: It is not a number. It is a database.
MS. TEMLITZ: Exactly. I have a picture of that coming up, too.
FHIE/BHIE is the Federal Health Information Exchange and the Bi-Directional Health Information Exchange. This is a mechanism that we use to share information with the Department of Defense. We will talk about that -- we will see that in the diagram, too.
CHDR or C-H-D-R is the Consolidated Health Data Repository and CHI, Consolidated Health Informatics. You may be familiar with some of those acronyms. You are all shaking your heads. So, I will move on.
The Enterprise Unique Identifiers or ICNs are integration control numbers. You were asking earlier about a standard for this number. There actually is a standard. The ASTME1714-95 standard is for a universal health identifier and on the slide it even tells you that. It is 16 digits. It is a number, 16 digits, followed by a character delimiter. We have to use a V, followed by a checksum that is six digits and you can have even an encryption scheme that is an additional four digits. At this point we haven't implemented the encryption scheme.
Our current ICN format begins with either a 9 or 10 digit number followed by a V, followed by the six digit checksum and there is an example of what one looks like. So, this number that is assigned uniquely to each patient is the key to linking those patients with other person data across the enterprise. So, you get one of these numbers.
A little bit more about what an MPI is as defined by the HL7 Version 2.4 standard, so there is a standard that also helps to define what MPIs should look like and what they should have. I am not going to read this slide because you have it in your notes. But really what it is telling you is that it can take these disparate systems as ID domains and correlate them and take these different entities -- they don't necessarily even have to be patients. They could be persons of other kinds from other systems and to correlate them under one unique number.
Some of the functionality that is also defined by the standard is that -- it is a cross reference or an index for these identifications. It provides methods to retrieve the information for a person giving a set of traits and demographics for that person. We talked a little bit about that set of traits that you use to determine what numbers should be assigned and how we determine that number and I will tell you what we store in our MPI in a couple slides.
The MPI uses matching algorithms. There was a little bit of conversation about that today, too. Currently, we use a deterministic algorithm. We are in the process -- we have purchased a probablistic algorithm. We are in the process of implementing that right now and we are going through some of the processes that were talked about where we are determining which traits we are going to use, how they will be weighted, what the thresholds are for saying that this is a match and what needs to go for more of a manual review.
This is more information about how we have implemented our master patient index. We correlated starting in 1997 the active patients, what we defined as patients that have been seen within the last three fiscal years from when they started the enumeration process. We took them from all 134 field facilities, generally medical centers, clinics and we correlated those under unique enterprise identifier, the ICN and that was completed in 1998 and that was the base that we started from.
The ICN is the system identifier. It is not intended to be used as something that is printed or viewable. It is a system identifier generally. It could be put on a smart card. It could be put in other mechanisms but it is not generally something that you would print out and have somebody bring and say, you know, like you might as a social security number. You are not expected to memorize it or have it readily available. It is used for system to system communications for the linkages.
I talked a little bit about FHIE. That is the Department of Defense, patients are correlated to our ICN using that framework.
MR. BLAIR: F-H-I-E?
MS. TEMLITZ: Federal Health Information Exchange.
We use a VistA. It is like a hybrid HL7 Version 1.6. It was developed by the VA that is based on the HL7 Version 2.4 standard to do our communications. That was mentioned earlier. It is a fairly standard communication mechanism. This is a diagram, pretty simplistic, of what the MPI looks like. So, the oval one on the top represents the MPI itself, the database that holds the ICNs, which there is an example of one there and the correlation is underneath it.
If you look at VistA site No. 1 and VistA No. 2, just as I mentioned, the patient that is in VistA Site No. 1 is given a DFN with that site number and that is a unique key combination. The same patient at VistA Site 2 has a different DFN because they were added into the system in a different time. It is just like a numerical assigned number, concatenated with that site number.
Those two sites are correlated to the one ICN number at the MPI. The pharmacy laboratory surgery registrations that are listed indicates that in our circumstance, which is probably easier for us, those all reside within that one VistA system. They are not just split systems. They are not separate lab systems. They are all software that is contained with VistA itself. So, we don't have specific identifiers for any of those systems. Within a VistA site, you only have one number, which is what makes it a little bit easier for us.
Then we have the FHIE/BHIE framework up in the corner there that communicated directly with the MPI to exchange information based on the ICN. Currently in the master patient index, this is the information that we store for each patient entry and this is stored for each correlation, meaning that we take this information from each medical center or facility that a patient is seen and we store this up at the MPI. Then we also have a primary view, which is located underneath the ICN. So, really what this is saying is we have used this information to determine that this patient at Site A and this patient at Site B are the same one. We are going to keep that information so that we can see that we made that decision based on these pieces of information.
We used patient names, first name, last name, middle name when it is available, date of birth, mother's maiden name, which is one that hasn't been mentioned earlier, but it is something that doesn't change, something that is, you know, unique to you. So, we use that. Place of birth, city and state also don't change. Alternate IDs, SSN. We also have the advantage of having the claim number for many veterans, which is a unique number. Lots of times it is their SSN, but deprecated ICNs, which we can explain a little bit later, but that is if there is a duplicate, one of them is inactivated, but we always store that with the patient so that you know that other IDs had been associated with that patient, and date of death, if there is one, and MPI-related data, which is the ICN itself and correlated IDs, the DFN and station numbers.
Here are some current statistics -- yes?
MR. BLAIR: Are you saying -- and this may be visible to everyone that can look at the screen, but are you saying that the MPI does include demographic data or the MPI is the ICN and the DCF and just the numbers for the site?
MS. TEMLITZ: It does include the demographics. The small set of traits, the demographic traits that are used to substantiate that identity.
MR. BLAIR: Is in the MPI.
MS. TEMLITZ: Are stored in the MPI, in that index, yes.
MS. TEMLITZ: Some of the statistics, the current statistics for the MPI as of the beginning of this month, it contains 16.2 million unique patients and 17.2 million correlations, which, you know, that is a bigger number. That is the difference between how many other sites the patients have been seen at. So, those correlations are counted as those unique DFN station numbers.
We add approximately 20,000 new patient records each week to the MPI. So, it is growing pretty quickly.
So, where do we use this number? We have it. It is unique. What do we do with it? Some of the current applications that we are using that use the ICN are, as we mentioned again, FHIE for exchanges with data with Department of Defense and we can do that real time through a remote data view. The next slide, I believe, shows a snapshot of our computerized record system where you can see how you can access that.
The computerized patient record system, CPRS, also includes remote data views and inter-facility consults with other medical facilities that a patient has been seen at. So, if I present myself in Milwaukee and they pull up my medical record and have been seen in four other medical centers, you can access that data, say on health summaries, labs, pharmacies, those kinds of things, real time by clicking on those connections there.
My Healthy Vet is an application that veterans can use to actually request RxRefills, prescription refills on line and that is fairly new and we are using the ICN to do that, to match up to the MPIs to ensure that they are actually in the database and to find the information about them.
This is not a very good slide. I apologize. But this is like a snapshot of what CPRS looks like. Up in the right hand corner, where the red circle is, you can see that remote data. That would be highlighted and when you press that, it would show you the other facilities where the patient had been seen and allow you to access information in summarized form for those sites.
Down at the bottom you can see where you can access all the different lab reports, discharge summaries, surgery. Now because this topic was specifically about, you know, matching patients and patient selection, we put this slide in here to tell you a little bit about how we actually go through the process of collecting this trait information and going through the process of identifying how patients are linked up.
We do collect the initial identity traits each time a patient presents, name, social security number, date of birth, gender. A query at that time is made of real time to the MPI to look for a match and as I said, at this point it is a deterministic match. It has to match exactly. Every trait that is provided has to match exactly in order for it to say, yes, this is the same person.
If that doesn't happen, it can come back and say there is nobody that even looks remotely like this and it will add it as a new patient or it can come back and it can say there are a couple that it looks like it could be. So, I am not going to tell you that I can match and it goes into a bucket. That is another technical term, a bucket. It goes over and we have points of contact at each of the medical centers that have tools, that allow them to review those and it gives them the information that was entered at their sites and what resides on the MPI and they compare those and they have the opportunity to pull in information from DBA, SSA and other sources to make sure that these are or are not the right patient.
As was previously mentioned, we also have the policy that if you don't -- if you can't tell for sure that they are, you don't match them. We just leave them up there as two separate. During this registration process if there is a match found, if the information goes up, it matches exactly. We actually have the ability to pull down information, some additional demographic information that was input to other medical centers about that patient and that could be military service information, income verification information, that sort of thing. That is an application we call Register Once.
So, if they do make that positive match, it allows them to pull some information from other sites. Other ways that we do patient selection and patient look up within that CPRS application, we do have patient lists that can be set up by physicians, by ward, and patients can be selected that way. And you also can enter identity traits, such as a social security number, first name, last name and those will pull up your patients for selection.
Now I am going to tell you a little bit about the structure we have within VHA to support our identity management function. The first is the data quality coordinator, who works under health data and informatics, which is part of the Office of Information within VHA. In that role, they really coordinate a lot of the activities for our interactions with other agencies within the VA, VBA and NCA.
We have a big section that does data standardization. Patient safety is a really -- I guess that is really a big concern of ours and then identity management is a component of that as well. To drill down a little bit, the identity management data quality program, which is what I am a part of, really has taken ownership of the data stewards of this identity data.
We participate in defining business roles, processes, to improve the whole identity management process, starting from how the information is gathered about patients to ensure that that we can get the best match that we can. What happens after that information is collected, how the matches are made, the processes that happen after the matches are made and to also address some of those patient safety issues and look at those -- the business processes around those to find out why they are happening.
We also resolve existing data integrity issues on the MPI and at the local VistA systems, do a lot of coordination with duplicate entries resolving duplicates if they can find out if they are duplicates, if they are not. If we have any data quality issues in data standardization implementation if we look at some fields -- you know, we have issues like people will put in mother's maiden name unknown or deceased or, you know, to try to alleviate some of those kinds of issues.
We also do a lot of what we might call marketing or training. We are trying to really raise the awareness of what the MPI does, the impact of what people are doing at the local site now has on the national systems. It used to be that each medical center was pretty much stand alone and what went on in your database kind of stayed there. But now with so much information sharing, it is really important that they understand everything that they do at that level really impacts lots of other systems.
Some of the other things that we are working on, we really have a focus on data quality because we are part of the data quality component. So, as I mentioned, we are looking at not only process issues but also in software design for patient selection, patient data entry, what we can do to improve those processes to improve the matches. Data cleansing and integrity, I mentioned that. Patient safety issues and the prevention of those, we have some real cause analysis going on right now to look at why we are getting some of the big data issues that we are.
We have mechanisms in place to identify if we may have what we call a catastrophic edit, which is where a patient entry may be selected and some of the key identity traits are changed and they actually change the identity of the patient record, which may have been linked to other ones. The software detects that those changes have been made and it triggers off alerts to two different groups to follow up on that and identify why that is happening or why they might have been doing that.
We do a lot of education on that, too. Why would you be changing these traits. You know, normally you wouldn't change the last name and the social security number at the same time in the same session, unless, you know, you were actually changing the patient.
Again, identification of data anomalies as I mentioned and some analysis and resolution of some of those data quality issues that we find system wide. This is just our resource slide. I put this in here. My e-mail is on here. This also contains our documentation that is readily available if anybody wants more technical information or even more user information.
We also have the data quality group, the Data Quality Management Team as it is listed on here, has a lot of user level information, you know, power point presentations, user manuals, information It has statistics on some of the issues that we have going on, reporting on how many patients are being added, those kinds of things. All of that is available on there, too.
I can let you ask questions or, you know -- okay.
MR. REYNOLDS: Are we going to do the last presentation or do you --
DR. WARREN: We seem to have gotten more time. So, do you want to ask about the VA right now?
MR. REYNOLDS: Let's go ahead and ask questions now.
DR. WARREN: Jeff is first or do you want to be first, Harry?
MR. REYNOLDS: No, Jeff can be first. I was trying to work the process and he puts his hand up.
Jeffrey, you are first. I would like to be second.
MR. BLAIR: Help me understand the ICN number a little bit more. Is there any demographic information that makes up that 16 digit number? Is it purely a random number or is there any intelligence in it?
MS. TEMLITZ: Well, it is not random really, but it is sequentially assigned.
MR. BLAIR: It is sequentially assigned. Okay. Other than it being sequentially assigned, is there any fields in the 16 digits that is --
MS. TEMLITZ: No, and that is part of the standard is that you can't break it apart and find out any information about a person that would identify them.
MR. BLAIR: Okay. If that is the case, why have you found it necessary to supplement using the ICN with a probablistic approach?
MS. TEMLITZ: Well, the probablistic algorithm, why we are going that route is to help -- it is not really, I guess, directly related to the number necessarily, but when we have new patient entries and we want to know if they are the same person so that we can match them together to correlate them.
We find a lot of those same things that previous speakers have talked about. A veteran will go to one medical center and say that his name is Jeff and then he will go to the next one and say that his name is Jeffrey. For whatever reason they have a hard time consistently providing the same pieces of information when it might be obvious to most of us looking at the record, that they are the same patient. A deterministic algorithm leaves no room for any variation on -- if you spell Jeffrey a different way, just because the registration clerk wasn't careful enough to actually check that spelling, the match won't be made.
The probablistic algorithm gives us a lot more flexibility in being able to say theses two Jeffreys, if all of these other fields are the same, our tolerance will allow those to be matched and determine that they really are.
With the deterministic algorithm, those would be bumped off to a manual process, which, you know, is really intensive. If we feel that the confidence level is high enough to tell us that those match, we would like those to match automatically.
MR. BLAIR: Maybe the piece that I don't quite understand is that if you have the 16 digit number, why don't you just use that since that seems -- is it not definitive? Is there still a certain percentage of the time when if you use the ICN number that you either have a false positive or a false negative?
MS. TEMLITZ: Are you asking would somebody bring in their number and just say, you know, here is my card --
MR. BLAIR: Yes. This is me. Here is my 16 digit ICN number. Is there anything else that you really need besides the ICN number?
MS. TEMLITZ: We do use other fields for verification. You are talking about for patient selection and I am talking about like entering a new patient into a system that hasn't been there before. That is when the algorithm really comes in. And the algorithm can also be used for look up. You are right. If I don't know my ICN, if I don't have a card with it, I will give you my name. I will give you my social security number. I will give you my date of birth and then it takes those fields and it goes up and it looks for it.
MR. BLAIR: That is how you use that.
MS. TEMLITZ: Right.
MR. BLAIR: I see. It is used by DOD and VA. Any other federal agencies or any other parts of the country that is using this?
MS. TEMLITZ: Well, I mean, we use it throughout the entire country, you know, throughout VHA, which is in all of the medical centers, 138 of them.
MR. BLAIR: And DOD uses the same standard ASTM standard number?
MS. TEMLITZ: DOD has their own unique number. We use our framework to correlate our unique ID with their information. That is what that framework does. That is a whole other presentation that I would be happy to talk to you later. I don't mean to say that I don't want to answer the question but really right now it is kind of complicated.
MR. BLAIR: That is good to know. That is helpful. Thank you.
MR. REYNOLDS: The question I have -- well, first, thank you. Excellent and thanks for helping us through it. You mentioned this My Healthy Vet. So, what do they use to sign on?
MS. TEMLITZ: They get access in --
MR. REYNOLDS: No, no, what data do they use to sign on?
MS. TEMLITZ: Oh, what data do they use? I am not an expert on My Healthy Vet. So, if I misspeak and anybody can correct me in the room -- but they have a registration process where you can go in and set up your own -- you enter information. Anyone can do it. You could go and do it. It is a web site that you access and you enter in your registration information.
Right now I believe that the way that this works is that those traits, when they want to access their information to see if they can get a refill, those traits are sent up into a query and they have to match exactly. If they don't, that gets bumped to a help desk.
MR. REYNOLDS: So, they don't enter --
MS. TEMLITZ: The ICN. Right.
MR. REYNOLDS: Because really that -- if I wrote my notes correctly, that is a derived unique identifier, not something they are walking around with as a standard identifier, is it?
MS. TEMLITZ: It is put on our smart cards, but they don't see it. It is not a number that they write --
MR. REYNOLDS: That is what I meant. So, it is not like you are walking around with your credit card and you can read your number off to somebody. They don't see it. So, it is a derived number that really connects your records. It is not a number that I am walking around with as a vet going here is my number.
MS. TEMLITZ: Right. And it doesn't need to be. You could give us those elements and we should be able to find it. In the future, what is going to happen is that the phase of My Healthy Vet, as I understand it is that you go into the medical center and you are proofed. You provide identification, two forms of identification with your picture and they verify all of your information and they give you these codes and then it will be -- see more the interactions between it because then we are going to link your vaulted information with the MPI and that link will remain.
MR. REYNOLDS: While I am asking this other question, could you put up the slide -- your Slide 10 again. The way it copied, it was all blank to us and I have some questions but I couldn't write them down fast enough. What it did was it blacked out everything on that.
While you are getting that up, the -- well, go to Slide 11 first. The information you have on Slide 11, so that is what you consider all the information that is needed to really match somebody back to this derived central number.
MS. TEMLITZ: This is a set of information that we have on the MPI right now. During the process of implementing this probablistic algorithm, we are now exploring using some other traits. We are using a vendor algorithm. We have purchased one, which is really unusual for us because all this other software is VA developed. We are only purchasing the small identity help. We are not using their tools or anything. So that it is more of a black box we just call it, that it is not vendor dependent. We are using their expertise to help us develop an expanded list of traits that we will be using in the algorithm because it is a more sophisticated algorithm. It can do more things. We have a little bit more flexibility.
So, we are going to incorporate some additional things we believe and we are looking at phone number. We are looking at address. We also have something in here that somebody mentioned earlier. We have a multiple birth indicator that we don't necessarily use to match on but we use it as a flag to say we have some issues with twins and sometimes they live together. Sometimes their first names are the same. We know that their dates of birth are the same and their social security numbers can be off by one digit.
So, we really felt the need to have some way to flag those so that we can say you better make really, really sure that these are two separate people and not the same ones.
MR. REYNOLDS: What percent hits -- on a general basis if you had a patient name down through, you know, the things that you have up there down through date of birth, what percent hit rate do you think you get on them?
MS. TEMLITZ: You mean how many matches do we get?
MR. REYNOLDS: As a percentage?
MS. TEMLITZ: To be honest, I couldn't tell you. I know that the registration people will tell us that it is really difficult to get an exact match on all of those fields when someone comes in and just gives them to them.
MR. REYNOLDS: What percent of your inquiries -- you mentioned a help desk. In other words, as we look at this whole idea of matching patients to records and you just threw out this new idea of a help desk. Okay. So, you know, if we go to just strictly data and you don't have a number and you can't really get as good a match then at this help desk. So, what -- I mean, does it hit -- most of us who run call centers, you know, you whether it is at 5 percent of the time, 10 percent of the time.
MS. TEMLITZ: You know, I wish I knew that. I should know that.
MR. REYNOLDS: If you get that back to Judy, that would be great. Because it is back to this whole process again that if --
MS. TEMLITZ: How effective is it?
MR. REYNOLDS: No, I am not going there. I don't want to go there because it is obviously very effective for you. I don't want to ask that question. I am just trying to understand as we try to build this and we try to get it to where -- because everybody that we have heard from somewhat today is kind of in what I would call a closed system. You know, it is the VA doing -- the VA and then you heard Texas dealing with the certain people in Texas and you hear the other people. Then when you talk about -- you start talking about NIHN and you start talking about where we are all going, they aren't closely knit groups that may be sending data back and forth. So, I am trying to -- the reason I am drilling down on the data is to try to get a sense of what data does it take, you know, how much and how broad and, you know, how standard does it take to really start hitting the match because as soon as we go outside our own little friendly areas where we have set the rules, all of us, you know, the game is different. And the game gets real different and then you start bringing smaller doctors in and hospitals -- I mean, you really start getting into a different game. So, that is no way negative to what you are doing. It is trying to move it to a different question.
So, the thing I was most fascinated with is since you don't have a single number, that the person tends to know and they don't have their smart card, then you are having to do this consistently. So, that is why I think you then become not a closed system to me because the person doesn't have a unique card, a unique number they are walking around with and so they are having to give you that information and that information is allowing you to get back to your uniquely identified number. So, I think you are a very good case for understanding how often that does or doesn't work.
That was my question.
MR. HUNGATE: A follow-up on the same content and make an observation. Question first.
Does the DOD follow the same standard in its creation of the number equivalent to your MPI or do they use a different standard, the DOD?
MS. TEMLITZ: You know, I don't know that for sure. They have what they call an EDIPI is what one of their numbers is. They don't have one number that covers all DOD right now.
MR. HUNGATE: I asked because earlier testimony talked about the issue of trust and it strikes me that the approach that you have, where the number is really not visible is more secure than most other approaches so that I can say that I am somebody who travels a lot. I am not going to live in a closed system, as Harry described. Your system is closed in the sense that somebody does have a number. There is somebody, a pre-registration from the prior visit and the matching problem is to align to that prior visit wherever it was.
It strikes me that I would like to offer a service or patient identification. I pay a fee on my credit card. I would rather have the security of being appropriately matched than have the risk of having mismatch with some other Robert Hungate, of which I know there are several, but they live in different places. So, it seems to me there is a benefit for a portion of the nation population to have some identity that gives them the assurance of getting into an index that properly identifies them. Call it a voluntary national identifier piece.
Is there anything like that -- I have heard that the VA system is going to be made available in a commercial version and I wonder if that commercial version will include this patient identity piece.
MS. TEMLITZ: I think what you are talking about is like the office -- the software and the database that we use for our MPI is public domain software and we recently had some requests for that software in the documentation, as well as the schema for creating the ICN -- and the reason I know that is because there was discussion about is that something that we can release. The answer is yes because it isn't something that you can pull apart to find someone's -- it is just sequential numbers.
MR. HUNGATE: I think there is a significant portion of the population that would like to be able to be assured of proper identification. You know, I have relied on my social security number, but I hear some threats that say maybe that is not so reliable anymore and I might like a better version.
DR. WARREN: Wanda, did you have a question?
MS. GOVAN-JENKINS: Out of curiosity, before 1998, what patient identifiers were you all using and ICN now -- I mean, what are the benefits and challenges do you have now for using the ICN?
MS. TEMLITZ: The patients that existed before 1998 --
MR. BLAIR: What date?
MS. TEMLITZ: 1998 is when we finished --
MR. BLAIR: 1998. Thank you.
MS. TEMLITZ: We do have 7 million plus patients that reside on the systems that haven't been enumerated yet. We do have plans to enumerate those at some point, just to have them all have a number. So, they are inactive patients. If they would become active, if they show up in a medical center or they have some activity, they are assigned an ICN at that time. So, that is just a note to say that.
Before we used the ICN, we were dependent on the DFN station number probably. There wasn't as much information exchanged between the facilities really. I think we did some look up space on social security number and name combinations to exchange data between -- I don't know. But now all of that is done with the ICN and inter-facility consults, which I kind of touched on, I mentioned it but I didn't really say how that works.
As long as the patient is in your medical center database has been assigned an ICN and the patient at the other medical center has been assigned the same ICN, they have been linked up, you can request a consult at another facility and get those results back at your facility electronically, you know, without any manual intervention required.
So, it has really facilitated a lot of inner sharing between the medical centers, where we have lots of patients that in a geographical area, they might get some treatment in Milwaukee and some in Madison and they can easily heed the results of that and exchange the information. That, I think, has been the biggest advantage to having the ICN.
MS. GOVAN-JENKINS: Actually when I leave here today, I am going to call my father and ask him, you know, what is on his card because he is a VA, but you mentioned that on the card they have the ICN number but then you said they don't have -- I mean, do they have it on their card?
MS. TEMLITZ: It is on the stripe. It is not printed on the card.
MS. GOVAN-JENKINS: Thank you.
MR. BLAIR: Related to that, now it is 2006, if somebody is honorably discharged from the military, DOD, they apparently already have that same standardized 16 digit number, does the VA have to issue them a brand new number or can they continue to use that standardized number from DOD?
MS. TEMLITZ: Well, certainly they can use that number. You are asking really good questions and you can't see my facial expressions, unfortunately. The reason that I am in Washington, D.C. -- I am from Wisconsin, but I have been at a meeting for the last day and a half with other VA agencies, BBA and NCA, because we are looking at sharing our identifier that VHA has with these other agencies in anticipation of the linkage with DOD. We now have real time medical data exchange when we have the linkage made, but -- so, we are doing some of that, but what we are working toward is this seamless transition from active duty to becoming a veteran.
MR. BLAIR: So, you are working to do that?
MS. TEMLITZ: Yes, we are.
MR. BLAIR: Then actually then maybe you could also help educate us a little bit. What are the impediments or problems to being able to integrate the system? Now here you have a situation where you have the same standard format that you are using and all it is a matter of accommodating into one system using the same standard format. What are the challenges that you are facing now in trying to integrate?
MS. TEMLITZ: Honestly, a lot of them are business line related, lines of business.
MR. BLAIR: They are not technical. They are business.
MS. TEMLITZ: Technically, you know, we can come up with a solution to have that done, but, again, the trust issue. It is business processes, what information we can share between what business rules we have for who can update what information. All of that needs to be harmonized between the agencies before we can move forward. So, I think that is kind of where we are right now. We can map out some technical solutions to do that. But it is getting over those other obstacles and ensuring that we don't upset the operations of the --
DR. WARREN: In lieu of time --
MR. REYNOLDS: Do we have another presenter coming?
DR. WARREN: Yes.
MR. REYNOLDS: Let me ask -- so, basically, you are about to become a further model to watch because you are about to open your system. You are not opening way up, but you are opening it between two -- multiple government agencies that right now have disparate numbers.
MS. TEMLITZ: Right. They still may maintain disparate numbers, but they would be correlated, which is not what we are doing --
MR. REYNOLDS: And possibly under this ICN or something?
MS. TEMLITZ: Well, or we may just correlate our ICN with their EDIPI, which in essence accomplishes the same thing.
MR. REYNOLDS: To you then they almost become another site?
MS. TEMLITZ: Yes. In fact, that is how the remote data view does it now.
MR. REYNOLDS: Thank you.
DR. WARREN: Thank you. I wasn't expecting that last little bit.
The last presenter that we have is from the Social Security Administration trying to bring this around. This is John -- I am not even going to try because Maria -- you will have to say your own last name, John.
MR. CHLUMSKY: Thank you for inviting us today. We will try to run briefly through this presentation and leave time for questions.
This is Taz Witt Simmons, who works with me and is much more expert in digging down in to the details of what I anticipate will be some good questions, having listened to your questions with the prior presenters.
Before I begin, let me just say listening to some of the questions, I think one key thing to keep in mind here I will sum up in one word; context. I think when we go to answer some of your questions, the right answer to some of those questions depends on the context in which it is being applied. As we go through our presentation, I think that will become more apparent in terms of how we are coming at this. The context in which we are coming at this issue is we work in the e-government arena at Social Security. Specifically, how do we electronically authenticate that we have got the right person on the other end of the telephone or on the other end of the Internet and allow them to do business with social security electronically.
The first slide highlights the topics we are going to cover. I will just kind of run down that quickly. One is the bottom line here for us is the challenge of striking a balance and that has come up while we have been here listening. For us the balance is largely between preserving privacy rights, the security and integrity of the data in our system and also meeting people's evolving service expectations.
In doing that, the primary guidance for us right now and it is relatively recent is guidelines issued by the Office of Management and Budget that define assurance levels for how confident we need to be that we do have the right person on the other end of the line. Stemming from those were additional guidelines from NIST that tried to tie available technologies to those assurance levels so each federal agency didn't have to try to do that on their own so there would be some consistency.
We will review SSA's implementation of those guidelines. I will share with you for us what are sort of rules of thumb as we deal with people who aren't as efficient in dealing with these issues everyday in different parts of the SSA business process to help them often reengineer what they have in mind doing on line. A lot of times what we are looking at is entities trying to bring an existing business process into the electronic environment, but they want to do that in effect without authenticating anybody would be ideal because then we get lots of business and it is more efficient. But it turns out that is difficult to do. We will walk through that with you.
We will give you some examples of SSA's online services and I will just say to preface that that we have a very interrelated and interdependent services we provide in general as an agency with lots of varied customers that people don't always think about. Usually people think in terms of social security beneficiaries, but we also process the way of reporting information for all the workers in the United States and pass that data on to IRS.
As part of doing that business, we also -- that makes the employers our customers as well. So, there are services we provide to employers as well as other third parties. For example, we have for a lot of our beneficiaries, representative payees or folks who aren't able to manage their own funds. So, we need to interact with third parties. We also have third party helpers, who help people file disability claims, more complex tasks and we also have other federal agencies as customers.
We will lay out challenges in three general areas and those are authorization, authentication and activation and we will explain more about the distinctions we make there later and we will tell you about our experience and we will open it up for questions.
In striking the balance, SSA takes very seriously its stewardship of public funds. That includes the fact that the baby boomers we all hear are getting ready to retire, but from our perspective, the wave has already begun because we don't just provide retirement benefits. So, that wave that is moving along, we are already getting to experience the impact of providing survivor's benefits and children's benefits to the spouses and offspring of those baby boomers.
Some of those baby boomers, many of them become disabled before they reach retirement. So, we are already seeing those cases and the retirement wave is just beginning. In order to do that with as with the rest of the Federal Government, we are not getting lots of additional staff resources and other kinds of resources. We have got to find ways to become more efficient and we keep doing that but one of our hopes for the future is that we can do more business online electronically with more customers in more settings and help offset some of that wave coming through.
We are also very concerned about protecting the information that has been entrusted to the agency to preserve people's privacy and people's service expectations are changing. People are increasingly expecting they should be able to do business with us online or over the phone if that is their preferred service channel. We have got to rise to the challenge of doing that. That is easier in some areas than others.
I am not going to get into it too much, but the OMB guidelines I referred to were issued back in December of 2003 and it was OMB Memo 0404. It lays out four levels of assurance and just to summarize those, at level 1, there is little or no confidence that the asserted identity is valid. For us that is kind of an irrelevant category. For us the two primary ones we are concerned about are level 2 and level 3. Level 2 says there is some confidence that we have got the asserted identity as valid.
Level 3 is we have high confidence that the asserted identity is valid and level 4 is there is very high confidence in the asserted identity as being valid. That is a pretty high level to hit. So, we are not too concerned about that on the whole because we wouldn't do enough business at that level to make it worthwhile at this stage.
There you are talking about things like PKI certificates at the level 4 and they are just not ubiquitous enough to be practical for us in the short run. In terms of the levels, under the NIST guidelines, which were issued in 6/2004 and on the slide we have got the reference if you need to go look it up for some reason.
At level 2, we are talking about what we call single factor authentication and those factors are either something you know, something you have or something you are. At the level 2, you need one of those factors and to give you examples, a lot of what we just saw in the prior presentation in terms of names, social security number, place of birth, those are things you know.
Things you have would be things like a PIN and a password, some sort of a token, a soft token or a hard token and things you are are biometrics of various sorts. At level 3, you need multi-factor authentication, which means you need two or more of those things. So, you need some combination of something you know and something you have or something you have and something you are. You get a little more assurance that you have got the right person on the other end.
In terms of SSA's implementation of the guidelines we have received -- and I have to say SSA had some of its services online before the guidelines came out and happily we didn't find ourselves in an uncomfortable place when they did come out. We were all heading in the same direction.
In our implementation, before we put any application up, we have to do privacy and security reviews. In effect, we have to certify and accredit -- I am sorry -- in the security reviews, that is really part of our infrastructure. At least every three years we look at our technology infrastructure that provides Internet services, for example, and we certify that it meets all of the requirements to be secure.
As we are putting up individual applications within that environment, we need to do authentication risk assessments and that is, I think, the thing we are focused on mainly here today. In order to do that, first we have to establish the general functionality of the application, exactly what is it going to do and how is it going to work. What is the user experience going to be like? What are they going to see on the screen? What are they going to provide to us? How does that business work from end to end?
When we have got that laid out with the project team, my staff facilitates a discussion with them to walk them through the OMB guidelines and the NIST guidelines and establish what seems to be the appropriate assurance level for the application the way it was designed and come out the back end with recommendations about at what level we need to authenticate people and how we are going to do that.
Sometimes, frankly, that comes out in a way that people aren't happy with. They find they are at a very high level and we have got tools that help them go back and look at what aspects of their business process caused them to bump up to that level so they have the option to go back and think about retooling and how this might work. So, they help strike that balance between privacy and service.
Having done that, sometimes we find ourselves in a place where we know we are taking calculated risks. So, we look at risk mitigation strategies. An example of that is, for example, will we allow people to do electronic change of address. We will send a physical mailing to the address of record saying that that -- we have taken that action at the person's request and we have had occasions where we get a phone call saying I didn't do that, the kind of cases that are most typical -- and this happens in our field offices occasionally as well as -- an estranged spouse coming in, maybe a divorced father, who is trying to redirect the benefit check of their disabled child. There are all kinds of situations out there and we see them all.
So, we have to allow that that could happen and, again, striking that balance between making it easy for people to do business with us the way they want, that understanding that everybody is not well-intentioned.
The rules of thumb we share with folks as we walk them through these facilitated sessions as we are telling them to start thinking about their applications, because the OMB guidelines are good, but they can be difficult to work through on your own. They are kind of voluminous and so are the NIST guidelines. But as basic rules of thumb, the things that tend to cause things to bump up the assurance ladder are if the application is only going to collect data from the person and bring it into SSA and we don't typically let that data go directly into our master records. Somebody is going to typically look at it. We are talking about an assurance level 2.
The big thing that bumps you up to the next level is usually if we are going to disclose some information or propagate some information that already exists in our records to the screen, then you are in real danger of moving up. An example of this was in the first implementation of our online change of address application. That was all PIN password based. But one of the challenges we have is that for a lot of our customers we don't have a lot of repeat contact with them in the course of the year or even over several years. If you are going to change your address with us, you may never change your address with us, having given it to us once, and if you do, that might be the only time you ever do it.
In that situation getting the PIN and password from us is a convoluted process that involves a physical mailing, chances that you will remember that password the next time you go to use it probably aren't high. So, there was a lot of pressure to get usage of that application up and so there was a lot of push to move it down to become knowledge based. We just ask for names, social security number, a few other things and do it that way.
We had difficulty doing that and that is one of the things that led us to change our tools to help people better see what was causing things to bump up because it turned out the main problem we were having and the way we were talking past each other was nobody ever said retool the application. They just said figure out a way to do this knowledge base. The easiest thing was all we had to do was stop putting our address of record on the screen when we asked for the new one. All of the sudden we could drop down a level and that solved that problem. But it took us quite awhile to figure out how we weren't asking each other the right questions.
Moving on, there are examples of the kinds of services we have on line. You can change your address on line. You can start or change your request for direct deposit of your benefit checks. You can request a statement of benefits be mailed to your address of record. We do benefit statement mailings -- was it age 22 and above now?
PARTICIPANT: That is the social security statement.
MR. CHLUMSKY: And you can also view benefit information online. The challenge areas for us are three. I mentioned authorization, the first question for us if you come in on the Internet, for example, first we have to figure out do we even have an account for you to access.
One of the challenges in this area is that people will assume we know a lot more about them than we do and depending on what stage of life you are at, we know more or less about you. We know more about our beneficiaries than we know about workers. With our beneficiaries, we can ask you things like, you know, what is your monthly benefit amount within a certain number of dollars.
But you would be amazed when you ask people things like what is your mother's maiden name, how often they answer is not something that matches our records. Often our records do say something like -- or place of birth unknown or people might know their mother's name was Phillips, but they aren't quite sure how it was spelled. So, in terms of doing knowledge-based authentication, we have had difficulty with things that you would think were fairly common knowledge and you could get about anybody pretty easily and yet the individual doesn't know. So, that is a challenge.
The second challenge here is authentication. Having established that we have got a record here that goes with somebody by that name, now how you going to show me that that is you. Are you actually the right person? The primary two ways we do that now are knowledge-based, which involves shared secrets of one type. These are the single factor things we talked about. What do you know?
For the most part, we have been relying here on using tolerances in terms of doing matches. So, we are not using fuzzy logic at the moment, but what will allow you to be a little off. We only match a certain number of characters or something. We are exploring using fuzzy logic, but there are some issues there and I think the right answer there is going to come back to the issue of context. By that I mean depending on what assurance level we think we need, given the risk of a mistake here. Maybe in some cases we are willing to go with a fuzzier set of logic for the match than others because the risk of a mistake is smaller. But we are still thinking that through.
We also issue user IDs and password, which then puts us a multi-factor situation and one that is both something you know and something you have because we gave it to you. It is also something that most other people shouldn't have.
The third area is activation and that is probably a little more transparent to the customer, but for us this is an issue of efficiency and for the customer, it could be that things move a little quicker for them, though they might not know it. This is really if we go through asking all these knowledge-based questions and activating an account and saying, okay, somebody has come in. They have given us this information. There is an account here. Do we have to go through that entire process again internally to reestablish all those links or do we in effect establish that we have activated this record the next time we come in. We could do some short cuts within our computer system to make this all go faster.
Our experience so far is that we have got a very high level of confidence so far that in terms of what we have done to date to authorize and authenticate and activate accounts. That has been going smoothly. Our online service use is growing and it is growing fairly steadily and dramatically. Between FY 2004 and FY 2005, for example, we had a 300 percent increase in our electronic services use.
We moved up from in 2004, 550,000 transactions to 1.7 million in 2005. We feel like this activity is in its infancy. So, it has got a lot of potential for growth. Having said that, we are also constantly monitoring the activity to maintain the integrity, security and privacy. So, we are watching to see -- we didn't know initially we would have these issues with mother's maiden name, for example. So, we are constantly looking at the data, trying to figure out where people are dropping out of the system or being knocked out of the system and trying to figure out why that is happening and do we need to tweak it further.
One thing I will mention based on the questions I heard earlier before we open this up for questions is that there are issues with private credit bureaus and we are exploring using other third party sources to get additional data to do knowledge-based activities. We are partnering with the General Services Administration. They have got the Federal Government lead for trying to explore some sort of a federated ID across the Federal Government. So, we are participating in that.
One of the things we heard from third party sources that are trying to do some of these linkages is that, in fact while a lot of us rely on social security numbers to match across various databases from different sources, they tend to be more dependent on things like telephone numbers. They are aware of the problem with people -- a lot of people using the same social security number and that is not a new problem. That problem has existed since the inception of the program. In fact, if you go to social security online and go into the search engine and were to type walletsocialsecuritycard, you will find an item on one of our history pages that talks about -- was it the late 1930s or early 1940s, Woolworth's issued or started selling wallets and the manufacturing of the wallet to help people better understand the kind of things you could put in your wallet, produced a facsimile of the social security card. I think it may have been the secretary of the head of the company in fact.
So, that number exists in our instructions to our employees as a compromised number as late as -- that history site will also tell you that as late as 1978, there were still 12 people reporting earnings on that number every year.
Back at the beginning of the program, people weren't quite sure what social security was, weren't quite sure what a number was, but, boy, they thought that was a great bonus that came with that 25 cent wallet. They got a social security number, too and saved, especially in a rural area, probably a trip of miles on horseback.
PARTICIPANT: Has anybody ever requested benefits?
MR. CHLUMSKY: I am sure they have.
We do have what we call a suspense file. We do these earnings postings every year and we do our best to give employers the right information to give us their information in the right format. We keep talking about exchanging information between computers, but for the most part that information didn't get in there, except through somebody's keystrokes, based on somebody's handwriting. Especially the further back you go, the less accurate some of that data is. So, there are always problems, either people deliberately reporting on the same number, someone else alluded to illegal immigrants, sharing numbers. That happened. Or people mistakenly transposing digits. That happens.
We have some fairly sophisticated algorithms that that part of social security uses to try to sort that stuff out, but inevitably that suspense file creeps up every year in spite of our best efforts. We hold those and at the time people come in to file for benefits, if their earnings record shows what look like unusual years of no earnings or deceptively low earnings, we will ask them if they can help us reconstruct were they working and can we find that in the suspense file. We are always looking for ways to improve that process as well.
One other thing I will share and then open it for questions. Context is in terms of the kind of data we can ask people for and expect they will be willing to share with us. We have done some internal surveys with our potential customers and somewhat to our surprise, when we asked them about the kinds of information they might be willing to give us, in order to do business with us electronically, I guess not surprisingly 90 percent or so of them say that if we ask them about their name and their social security number and that sort of thing, information SSA already has about them, they have got no problem with that.
I think it is about 70 percent said that if we were to ask them about other information that some government agency has on them, that they would be okay with that, too. So, a driver's license -- I am not sure about the 70 percent. I will double check that, but it was somewhere in that range. Something like a driver's license or some other information that they probably assumed the government shares, they don't have a big problem with that. But when we asked them about things like sharing with us credit card numbers, bank account numbers, 4 percent say they are comfortable with that.
You have to keep that in mind that that is their perceptions of what they might be willing to do versus once they get in there and they are trying to do a transaction, but I come back to the context issue. I think a lot of it depends on who they are doing business with and does it feel right. If they are coming with us and they are trying to set up direct deposit, they probably feel pretty comfortable giving us the routing number for their bank because otherwise how else are we going to do this.
If they are coming to change their address and we want their bank routing number, well, why do you need that? And if you are going to VA or someone else, someone who is providing you with health care services, if you are used to providing them with a credit card number in order to get services, you might be willing to provide that credit card number to authenticate yourself because it feels right in that context. But why does social security need that from you?
So, I think that is something to kind of keep in mind that people's reaction might depend on in what context you are asking for it and does it intuitively make sense to them. So, having said all that, I will throw it open for questions and Taz will help me answer.
DR. WARREN: When you talk about information and context, I am wondering if that isn't one of the key issues. A couple of the other presenters have talked about trust levels when they were looking at ID as a context. So, this context may have a real critical piece with that.
I just wanted one piece of information and if you don't have it, that is okay, but about how many new social security numbers are issued a year? Ballpark number, not anything close.
MR. CHLUMSKY: I really don't know off the top of my head.
MS. SIMMONS: Most of the social security cards are issued that are new that are issued are an enumeration of births. So, when a child is born -- so that is how most of the social security numbers get issued.
MR. CHLUMSKY: We can get that and e-mail it to Maria, though, if you want.
DR. WARREN: That would be good. One of the questions we have had in the past has been if social security number was talked about, about being a unique patient identifier, would we have enough numbers, how much would it cost to issue them or if we created a new number, how much would it cost, you know, to create the new number and then dispense it out. That is probably a question Stan would ask.
With that, I will open it up to questions.
Jeffrey. I am sorry. He holds his hand up first.
MR. BLAIR: First of all, I am really pleased that you have made the move to more of an electronic environment and because of that some of the things that were concerns about the use of social security number as an identifier within a health care setting, that NCVHS identified I think it was eight or nine years ago -- I guess it was eight years ago -- maybe some of those limitations or constraints either don't exist anymore or have been mitigated. So, for example, now that you have it in electronic form, do you now make social security numbers available with a check digit?
MS. SIMMONS: You mean like a checksum to check it to make sure the digit is correct?
MR. BLAIR: Yes.
MS. SIMMONS: No. No, we don't.
MR. BLAIR: When somebody passes away, is it possible that that social security number can be reissued to a new child or a new person?
MS. SIMMONS: We have never reissued a social security number, to the best of my knowledge.
MR. CHLUMSKY: No, we haven't.
MR. BLAIR: At that time when we were looking at it, there were situations where there duplicate social security numbers. Do you know what the status of that is at this time?
MR. CHLUMSKY: You mean multiple people using the same number or one person having multiple social security numbers?
MR. BLAIR: Multiple people having the same social security number.
MR. CHLUMSKY: We don't have multiple people that we have issued the same number to, that as I said earlier using the Woolworth's card is one example.
MR. BLAIR: -- verify that now that hadn't been in existence eight years ago.
MR. CHLUMSKY: Well, going back to what we have heard from third party vendors, people are always worried about big brother, but if you look at the private sector and the information the private sector shares with each other for various purposes, whether it is the credit bureaus or selling information to each other for purposes of mailing lists and other purposes, whether you are checking videos out of a video rental facility or buying pizzas from a pizza delivery service, there are third party data aggregating companies that pull that data together and even in cases -- and these are the folks that say that they tend to rely more on things like people's addresses and not necessarily just a current address, but what addresses have you ever had, what phone numbers have you ever had. For them that kind of data makes it easier for them to differentiate between individuals, individuals in the same household, potentially individuals using the same social security number.
MR. BLAIR: Let me ask my question a little differently then. Within the last eight years, what processes or procedures, especially now that you are electronic, are you able to do to try to verify that an individual is validly identified with that particular social security number that you weren't able to do more than eight years ago?
MS. SIMMONS: We have an internal system that is electronic that controls social security numbers, the applications of the number and the issuing of the number and it has been more than eight years. I couldn't tell you exactly how many years, but I think it was back in probably in early eighties when that was put into place. Before that, was there a possibility that someone could have gotten the same number because it was done manually? Yes, people are human. It is possible that we could have issued the same number to more than one person, but since we have gone to the electronic, I don't know that we have issued the same number to more than one person because we have it all in an internally built system.
MR. CHLUMSKY: And those numbers are all mailed out from a central location. They are not distributed locally anymore.
DR. CARR: I am just looking at -- to the question of how many specifically OQA stated in FY 1998, SSA issued 2.4 million original social security numbers. Is that helpful?
MR. CHLUMSKY: Electronic services? Thank you.
MS. GOVAN-JENKINS: Because of identity theft, have you all thought about perhaps -- I just thought about this -- adding a letter to our current social security number in order to make it less invasive?
MR. CHLUMSKY: There have been a lot of proposals. Congress is constantly thinking about whether to try to mandate additional -- to make social security cards more tamper proof, for example. All of those things tend to be very cost effective -- cost prohibitive and it is not just the numbers, not just with social security but anything else. The main thing in the authentication arena is what kind of proof did you have in the first place that you were given this number to the right individual.
So, when we talk about social security number as an identifier, it really isn't and it never has been. It has become kind of ubiquitous in the private sector as for the shorthand way to try to differentiate people but social security has never provided the assurance that that is a hundred percent sure because as we said we know there have been compromised numbers. We do everything we can to keep those records straight but we have never promoted it as a national identifier.
MS. GOVAN-JENKINS: Well, if you thought Y2K was bad, try changing the social security number. It is out there everywhere. Everybody uses the social security number in some fashion. Some of them legitimately. Some of them not. But IRS, SSA, VA, every medic, almost everybody you go to get medical service now will ask for your SSA. Credit reporting is done by SSN. So, all of that would have to change if we changed the structure of the SSN.
MR. CHLUMSKY: It is used a lot in the private sector and you are not required to give it to anybody in the private sector, but they are not required to give you the service you are asking for either. So, people tend to give it up.
DR. WARREN: Any more questions?
Thank you very much.
MR. REYNOLDS: Thank you. Very, very interesting.
DR. WARREN: Okay, Harry. It is yours.
Agenda Item: Subcommittee Discussion
MR. REYNOLDS: The next part of the program is obviously for subcommittee discussion. So, the first thing I would like to do is make sure that we spend at least half of the 15 minutes of the time on what we just heard and what we want to do next.
One of the things we had kicked around was the idea of -- well, first, I think we need to answer have we heard enough to start drafting some thoughts. Second, if so, then, you know, what is our time frame that we want to shoot for to try to bring something forward out of it for consideration.
So, Judy, let me let you start first.
DR. WARREN: Well, the notes that I was taking is I thought it might be useful if we again asked HL7 and ASTM to come talk about the standards they have for identifiers, that at least that would give us some of the technology pieces behind it.
Several people have been asking about DOD. So, I didn't know if we wanted to know what they were doing or whether the response we got from Sara at the VA that there seems to be this group coming together under the federal architecture that are eventually going to link in with the DOD. Do we leave it at that or do we really want to hear from them?
Steve, don't leave yet. Was it the IHE? Okay. The IHE effort which is really looking at interoperability and sharing data across systems, that they might be appropriate to bring in.
DR. STEINDEL: Judy, we discussed that in the NHII Workgroup yesterday, about bringing in them and I think it would be very worthwhile for NCVHS to hear from them and I think we need a discussion of exactly where and who.
DR. WARREN: Okay. Those were my thoughts of testimony that we have not heard yet.
DR. STEINDEL: With regard to the FHA, obviously, this is not going to be a factor because I think our next meeting is in April. They are undergoing some reorganization changes and I don't think we could get a designated speaker, you know, for the next month or so, just because of those changes.
DR. WARREN: Okay.
MR. REYNOLDS: I have got some other thoughts on this matter, but others of the committee, comments?
MR. BLAIR: I wonder -- and this is a question -- do we have enough information to begin to start to draft recommendations where we could get full get full committee approval in June? Or is our target date for that going to be the full committee meeting in September? If it is September or later, will it still be of value, given the fact that the nationwide health information network prototypes are going forward and part of those involve matching patients to their records? So, will our recommendations still be of value if they come in September or December or are we facing a situation where if whatever value we may have would probably need to get out in June? So, that is an open question.
MS. FRIEDMAN: I would like to just follow up on the timing issue and I don't know the answer to this. I have been sitting in on some of the discussions on the AHIC breakthroughs and also I sat in as an alternate -- I am an alternate on the interdepartmental workgroup. Of course, this issue about the master patient index and the unique patient identifier is right at the top of that list. As we all know, those groups are moving very quickly. I don't know what the answer on the timing issue is.
Having said that, I think we have information where we can start putting recommendations together. I don't know whether we have a full letter, but I think we have a partial letter going.
So, one possibility is just to keep going, maybe start working on the partial letter and if we see that things are unfolding so very quickly, we could maybe crank out the partial letter with -- you know, do more to follow. But at least get a chunk of it in.
MS. GREENBERG: I am just wondering if some of the -- I think you are right and you should know what DOD is doing and probably get more information on the standards and I can't remember what the last one you said was. I am wondering if some of that is just back flow or descriptive fact finding that could be done in a manner other than through a hearing.
MS. FRIEDMAN: I just thought it was interesting that this is the first time we really heard about the discrete standards in the way that we heard about them.
Now, we may have heard that information before, but it sure whizzed by me.
MR. REYNOLDS: I guess I have a process question being new at this. So, since it was brought up today that a standard exists, can staff get access to that standard and then us use it by reference in any kind of a document?
MR. BLAIR: Sure.
MR. REYNOLDS: In other words, all we are doing is getting the details of something that was brought to our attention in a hearing. So, I would like to -- I mean, so that is a possibility.
DR. WARREN: I think that is a very distinct possibility, you know, getting a hold of those documents and doing our own analysis and then bringing that in to the April meeting or even start sharing that by e-mail prior.
MS. GREENBERG: Then if you have questions, you could follow up.
DR. COHN: I apologize. I may be saying things that are completely either redundant or off point. But obviously there is a difference between standards on a unique identifier, which I think is a number of the things that you are all referencing, if my memory serves me right, versus what we are doing, which has to do with patient locators and matching patients.
I think they are substantially different things.
MS. GREENBERG: They actually use a standard for their master patient index in the VA.
MR. REYNOLDS: We are not recommending any standard. We are referencing a standard that they are using.
DR. COHN: That is fine then.
DR. WARREN: As part of the technical solution for a unique patient identifier, they referred back to those two standards. So, it is in that domain that we are looking at it. But I still agree with Harry. It is something we can look at offline, analyze it and decide whether or not we need any testimony about it.
MR. REYNOLDS: Well, yes, because what I think I found interesting, Simon, since you weren't here for that discussion, was the standard called for like a 16 digit number. Okay? So, I think it is relevant in the fact that if the standard is out there, a certified standard, not the standard would be recommended.
You know, you have got the social security number that is 9. You have got other things that are other thing and now you have got a standard out there that is being used by the VA that is up to 16. It is just --
MS. GREENBERG: Well, that includes the check digit.
MR. REYNOLDS: Yes, I know. I know.
MS. GREENBERG: Maybe I am wrong about this, but, Jeff, you may have -- you know, the report that was done for the national committee you said it was eight years ago. Solomon Apovu(?), is that the one you were thinking of?
MR. BLAIR: Oh, good. Your memory is excellent.
MS. GREENBERG: It seems to me it had information and it may be on our web site. It had information then about this ASTM standard.
MR. BLAIR: Well, I don't remember whether it had the ASTM standard -- I don't even know if the ASTM standard was even done at that time. It was an assessment as of that time.
MS. GREENBERG: So, this has been around for awhile.
MR. REYNOLDS: Let me jump in for -- if we could just adjudicate whether or not Judy and Maria and Donna have -- through process, have the ability since it was mentioned to access it and use it if we have them put together something to flesh it out more than we heard today because I mean it is -- the words are there. It is a standard. It is not something that anybody -- we would be adjusting necessarily. It would be something we are referencing. We may need more words on it.
I am talking process now. I think we will need to -- you know, to go back and forth on whether it is going to be in there, whether it is worthwhile, whether it makes any difference. But I am just talking about using it as an asset right now.
MR. BLAIR: I almost feel like the greatest value we could contribute at this point is that we have heard from the networks that are reasonably well-developed, that have come up with probablistic approaches. We have heard directly or indirectly from a vendor that many of them use, that has developed algorithms that are at least accepted by some of these networks, but we have also heard from a diversity that we may be the only forum that has heard from not only those entities but we have heard from the VA. We have heard from folks that are not using those algorithms. We have heard from folks that are developing their own and we have heard from folks that are looking at matching patients to their records in different use cases and settings.
That has a tremendous amount of value because for us as a nation, if those prototypes go forward, ,those prototypes while there is some diversity among the prototypes, there is some homogeneity among them as well. The testimony that we have received, I think, adds diversity to whatever those prototypes might be able to offer. That may be very, very important.
MR. REYNOLDS: One of the things I would like to then put on the table is that we ask Judy and staff to go ahead and put together what we have heard, group it together, whether they be recommendations or group it together so that we could have some kind of a consolidated document for our April meeting, to make sure that we at least start doing this.
One of the things I think we -- and I will take the credit -- we fell short on on some of the stuff that we were recommending the other day, was that we heard so much information over time, that we weren't grouping it up along the way in ways that we could keep ourselves in context. So, when we solve it, everybody has to go way back to what we all agreed to or didn't agree to, thought or didn't think.
So, I think some of the subjects that we are tackling are broad enough and I agree totally with Jeff. We have heard a very diverse set of people come and talk about matching records to records. Let's don't even go with patients to records right now. Let's go with records to records because that is what we are really dealing with in the end is information about somebody matched in lots of disparate ways that it comes in and it gets dealt with. So, that is what I would like to see because I firmly agree -- and Simon and Jeff and I have independently had some discussions on it. If we listen to what is happening out there -- and I know I have personally met with IBM in North Carolina about what they are doing, I believe these kinds of things injected into those processes now sometimes almost as information, even if it is not a full layer yet is going to be very helpful in the end game of where this country is going to go. Because there are four sets of people out there right now that are going to say something and that something is going to have -- it is going to have been fleshed out over a month or it is going to be fleshed out over three hours, but the point is it is going to come out.
So, I would like any comments on whether or not having Judy and the staff go forward would be the right thing. Judy, you have your hand up.
DR. WARREN: Well, I just wanted to bring up one more potential speaker that we might want to bring in in April. Eight years ago, we had Solomon Apovu come in and brief the committee. He has stayed on top of this issue in the intervening eight years. In fact, Wanda was looking for someone with the Federal Corrections Department and his name floated up because he does deal with the Illinois State Corrections Agency. He is also at ER and does some other things.
So, I don't know if we want to bring him back in as an update on what he originally did. I mean, I chose not to bring him in at this time because we had other people that we had not heard from. So, that is something else to consider.
MR. REYNOLDS: Since we have kind of given you the ball on this, if you feel that would -- so if we had him come in and present, but you still had this draft -- in other words I don't --
DR. WARREN: Oh, yes, we will have the draft.
MR. REYNOLDS: I don't think we can wait. Then what he does or doesn't say, does or doesn't effect that draft. At least we are still moving because I think the time frame is key.
Marjorie, I think she is going to comment on this and then, Jeff, I will get you.
MS. GREENBERG: I was just thinking you might ask him to review the draft.
MR. REYNOLDS: That is exactly what I was going to say.
MS. GREENBERG: He might say, oh, well, you don't seem to know about this if you don't have that.
DR. WARREN: That approach feels better to me.
MR. REYNOLDS: Because again I think the key point is we are asking you to draft a summary of what we have heard in the hearings that you think would be something worthwhile. We are not -- the reason I am not terming it a letter is we haven't decided what we think yet on that. So, we are drafting together and I would recommend --
MS. GREENBERG: Findings.
MR. REYNOLDS: Yes, findings. I guess one of the things I have learned recently in this is maybe after each meeting, whoever owns that subject maybe ought to be doing maybe a synopsis for all of us to keep us in the loop, just as a general thought. Because we have so much going on and there are so many diverse subjects.
MR. BLAIR: I so much agree with what Marjorie just said and what you just said. So, let me add -- so let me pile on and add to that a little bit. If we have our best initial shot at at least having our list of findings where we could share that with Solomon and he could comment, supplement, add, clarify, that could be such a fertile testimony and besides he has got -- you are right. He has been focusing on this and I think he would be an excellent person to clarify things.
The other piece that I am thinking of is that in terms of the findings and in terms of the of the role that we could play, how could we be helpful. I am having the impression -- and maybe when we do the findings, it won't turn out this way, but I have the suspicion that when we do the findings, there is going to be a group of findings, mostly the information we have gotten from the existing networks that have used the probablistic approach and the algorithms and those findings will wind up showing areas of convergence or potential convergence and that is good. That is probably going to be similar and support the prototypes that are being done.
But in addition to that, I think with the testimony we received, we are also going to find a group of findings that look like they are not converging, but they represent sectors of our health care delivery system whether it is VA or Indian Health Service or areas that are focused on research or different use cases, where there is not convergence. Both of these have great value and I feel like this is where we add added value in parallel, where we complement -- I am using the word "complement" -- where we can complement the work that is being done by the prototypes.
MR. REYNOLDS: Make sure we get everything we need to do today. If there is no dissenting voice, then we need to make a motion or do we just have Judy continue --
DR. WARREN: I have one question. In my preliminary thinking about of what the structure of what this letter looks like, I keep going back to the structure that we did on the e-prescribing letter because that really laid it out very clearly. So, that is what I have been thinking about, what I have notes on. Is that agreeable?
MR. REYNOLDS: And, again, we will be happy to work with you on that. That is good.
MS. FRIEDMAN: I think that is one of those things we learned from the last letter, that we needed to have some kind of observation and tee it up to provide context for the recommendations.
MR. REYNOLDS: Okay. Let's move to our letter, the letter that is in play.
Yes, Wanda.
MS. GOVAN-JENKINS: I have received in the research of looking for different, you know, people with, you know, correctional -- the process of having -- in the correctional system, I received several e-mails. So, I can summarize the e-mails on their process on what identifiers they are using in the correctional system.
MR. REYNOLDS: Marjorie, again, so I can learn, are we able to include such things even though we do not hear them in hearings?
MS. GREENBERG: Sure. It is information gathering.
MR. REYNOLDS: Again, I am trying to learn.
MS. GREENBERG: In fact, as I have mentioned in the past, information gathering is not covered really by the Federal Advisory Committee Act, but we usually do it in a public setting because it is a good way to get the same information to everybody and ask questions.
MR. REYNOLDS: That is good. Just trying to learn what we can or what we can or can't ask for.
Our letter, one of the things that Jeff and I talked about today about the letter is one of the things that we would like to consider doing is rather than calling this HIPAA ROI, which invokes many things. It invokes political things. It invokes people going back and looking at history. It invokes emotion. It invokes lots of things.
This is really HIPAA lessons learned and the things that need to get continued focus and it is also things that we would hope would be taken in consideration as any other regulation were to come out. But that three letter nomenclature rings a bell. So, it puts people in many categories. So, you can say exactly the same kind of things, but when you are talking about what actually did or didn't occur, what was realized or wasn't realized, in the first place there was a lot of discussion early on about what it was, but there was never really a template that said so after x years balance it against this.
There is also findings that we have, for example, that it was set up as expected but some other things need to happen to have it go the full thing. So, for example, our very first recommendation says that it would be good for providers to adopt the non-claims transactions. Now, the way it was originally set up in the regulation, they didn't have to adopt them. So, going in and saying whether there was ROI on that adoption for those, especially the ones that they are not having to do, starts bringing up issues.
So, all we are saying maybe we should change the flavor of the letter to be more progressive about what should go on from this point forward, rather than necessarily going back and taking it apart and maybe pushing some things that without really getting into dramatic detail, you can't necessarily defend. On the other hand, you are giving recommendations.
Simon.
DR. COHN: I have been around for a long time, in fact, even when HIPAA was passed. I actually don't in any way disagree with any of the direction -- I would actually ask the subcommittee, we have a couple of options in how we proceed with HIPAA this year. I mean, one is is that we produce a letter for June. Another is that we have an annual report that we are mandated to send to both Congress and the Secretary of HHS relating to progress of the implementation of the administrative provisions.
The question is is obviously writing a letter is different than producing an annual summary that may also include all of these other main points. So, I just sort of lay it on the table that, yes, we can come up with a letter focused on x or we can somehow, you know, talk about a lot of these things in the frame of a report, but with key things about really how we are going to make this even more successful than it already is or however you want to frame it.
MR. REYNOLDS: No, no, I got you. You had actually mentioned it -- I read the last report. So, I got a copy of the report to read and I feel that the things -- and I could use some help from staff and others -- I feel that this report is a state of the union of HIPAA. I feel that the things we had in the letter reference some of the same subjects, but are much more focused that something needs to happen to make it go. So, when I read this report, this report is a story of which some of these items are mentioned, but not as far as to say so here is what is recommended to do. The last two I read were more of a story painting the picture of what the journey has been.
Whereas, these six things that we identified are six things that we think need to be addressed.
MS. FRIEDMAN: We also don't have very many lessons learned in here either.
MR. REYNOLDS: No, no, because if I read -- what is interesting if I read, I could take most of the current report that we did in September of 2005 and copy it. I am not saying that in any negative or positive way. So, what I am saying is I am not sure that any of those went as far as our letters tend to go. The other thing is our letters to the Secretary give him and his environment a chance to deal with what they were responsible for, rather than necessarily at the same time -- that is just another thought. Not right or wrong or good, but just -- yes, Marjorie and then Jeff.
MS. GREENBERG: I think you would do both. I mean, if you do a letter, you also would include that in the report probably.
MR. REYNOLDS: That would be fine.
MS. GREENBERG: But I think it would be -- if you feel there are some things you really want to highlight, it would be done better by also doing the letter. Otherwise, it could kind of get buried in the report, but I think it would belong in the report.
MR. REYNOLDS: But I think, Simon, back to your earlier comment and then, Jeff, I will turn it over to you, we should go ahead and start preparing the report, our annual report anyhow. September is when we usually tend to do it, then we need to get moving.
MS. GREENBERG: Oh, yes, this is a timely issue.
MR. REYNOLDS: It is just whether or not we take these pieces out and do it twice, not really twice, use the same thing in two different ways. One may be as a story and the other as direct as possible.
Jeff.
MR. BLAIR: Simon, when Harry and I were thinking about this and we weren't sure which way we wanted to go and we were going back and forth and, you know, should it be in the report, should it be a separate letter and we began to think about it and we began to think of the issues and the problems and a lot of things. One of the things that kind of tilted us back to a letter, but not to -- as Harry pointed out, this would be a little bit of a different focus. The lessons learned is -- the letter calls for some action and it not only calls for some action that is needed to help, to try to finish things in terms of HIPAA to make it more successful and there are some actions that are needed there, but when we changed the character of the letter to lessons learned, it also winds up pointing out that there are some issues here in the way things -- the way we looked at things over the years. It is we. I mean, we looked at things this way, where we are about to head into clinical standards. We are about to head into terminology standards. We are about to head into harmonization of standards, a whole array of other issues.
The letter gives us an opportunity to get that -- to really highlight that out with a little bit of -- if there is action that is called for, then there is a focus. So, I think we could put it in both. We could do the letter and we could also include it in the report, but the letter does call for actions not only to improve HIPAA but also to put us in a better position with the other emerging standards.
MS. COHEN: Maybe I would slice this up a little differently and, obviously, I don't know exactly what this year is going to hold, but it is really a question of how we unveil all these pieces and I agree you there is a place for -- I mean, it seems to me there is a couple different pieces we have. One is efforts needed to assure successful implementation of HIPAA. That is a piece.
Then there is also called lessons learned, which is really a much more of a -- it is a different question. I mean, it is basically learning for the last ten years. We began to write that in 2002, Jeff, when we -- I mean, we are just now getting clinical standards. We have been getting into clinical standards since about 1998 and I think we wrote a letter that talked about some of that back then. So, it is not a new thing.
I think my own view is that the lessons learned may find itself much more appropriately in an annual report than it would be in a letter. It is just of conceptually that -- you know, somehow if the point of the letter is, by God, there is -- you know, HIPAA, a lot of things are going along well. Other things really need to be optimized and we really need to do x, y and z, try to meld that in with a bunch of lessons learned.
MR. BLAIR: So, you are still saying -- because Marjorie said something, which really kind of was something that Harry and I were thinking, too, is that if you put it in the report -- I think, Marjorie, your words were, in some ways it might be buried and won't get the attention.
DR. COHN: Let me frame it maybe a little differently here. I think that the things that need to happen need to be in a letter. I agree with you and it is probably a June time frame. I am actually wondering if at the September time frame, whether there may be an occasion marking the anniversary of HIPAA, at which point a discussion of lessons learned might be very appropriate conversation to have and I would rather hold it for something more like that. I agree with you. It shouldn't be narrated. I am not saying if we move to June, it might not cross and we may not see that it actually all comes together. I just think that the messages are very different about --
MS. GREENBERG: I am not quite sure how the timing is going to work out here. I think Simon and I are on the same wave length here, but one more time of the week, but it seems to me that if you want kind of a crisp letter that, you know, makes recommendations or gets attention, you would want it to be, no more than two pages or something so that you can refer to the findings and to the lessons learned as being included -- you know, you could just highlight them and then refer to them being included in more depth in the actual annual report. You would have to have both done at the same time.
MS. FRIEDMAN: I would like to pick up on the flavor of not getting the lessons learned lost and buried in this annual report that is a cut and paste job from the previous year, by and large, anyhow. I say that partially because of I am viewing the world from where I sit now and trying to get out the HIPAA modifications, next round of modifications and things like that. The world has changed a lot as we have all observed. On the ten year anniversary is appropriate to say not only, you know, we have really made it work but some of the things that might need to be done differently now or that, you know, we have learned that certain things do work in certain cases and certain things don't.
So, I would just -- my vote is to not let that get lost in the report and I see no harm in duplicating it in a letter.
MR. REYNOLDS: So, let's see if we can come to a conclusion today and then we can get ready for tomorrow morning.
So, Jeff and I will take off line with Maria and put together -- we already have a letter that had six key focus points. We would go ahead and adjust that so that it comes back to this group as a letter that would be complementary to an annual report that may be the ten year look back or whatever, that we would also be working on at exactly the same time. Okay, with a plan of that. So that in June we could have a letter, but it would be in context as to how it relates or April, we could come back with the letter, at least have fleshed out how in relation it will be to the annual report.
Then we are looking at July or September to have the annual report done. But not deal with either one of them, you know, in a vacuum. Make sure that we can explain as we do each one, how they are related to each other so that everybody can be comfortable, that we have got a good journey.
Yes, Maria.
MS. FRIEDMAN: I would invite -- in an effort to get the wisdom from the collective intelligence in the room here, I would invite people to send us what they think the lessons learned from HIPAA are, to e-mail Harry or me, so we can just kind of keep a list going. I think that makes the process more efficient, but I also think this is the last meeting we are going to have for awhile, it would just help move things along if people sent us their thoughts.
MR. REYNOLDS: Okay. So, for purposes of letting everybody get out of here as prescribed, is there any other business we need to do today. We will be back together, obviously, bright and early tomorrow morning.
Thank you very much.
[Whereupon, at 5:40 p.m., the subcommittee meeting was concluded.]