The HIT Policy Committee NHIIN Workgroup met on Thursday, January 7, 2010. The meeting materials from the ONC website and the rough draft transcript of the meeting are below. Also be sure to check out the FACA blog and the Health IT Buzz blog for the latest updates.
Rough Draft Transcript:
Good morning, everyone. Thank you for joining us on this early part of this year. If feels like July already. Only two or three days into the year. We have a very busy and aggressive agenda to tackle the issues of around authentication today. I want to thank the staff for have been working so diligently over the holidays to make this possible for this meeting to be together in pretty short notice. As we will see in a few minutes, we have done some great work on framing the issues and recruiting for today. I especially want to thank those of you will come today to share your expertise with us and having taken the trouble to prepare written testimony and come to this meeting. We really appreciate it. It will be very voluble. The agenda, as you imagine, is a few directory comments by myself, and Danny will be here and not a few minutes. Dave is in the bad traffic today, but he will walk us through some of the contacts for the authentication discussion. Then we have three panels including federal experts and a number of you from the private sector to help us understand what is happening there. We will then have some time for public comments. Any of you who wish to give us your thoughts at 12:30, we will do that. We will have a lunch break and continue the meeting at 1:30 with its session among committee members regarding what we understand from the testimony we have heard. And the meeting will adjourn at 2:30. With that, let me just set up a couple of thoughts from my point of view. Doug will walk us through some of the ONC background. How we come to this point and what we're after here, we are a branch of a policy committee and Standards committee. Our interest is in understanding, what can the federal government and various partners do to facilitate the rapid adoption of meaningful use by eligible providers and hospitals? We want to better understand, what are the key infrastructure elements needed to facilitate health information exchange in support of this? In other words, we are not interested in a deep dive into the technical issues around authentication or options before us. We want to understand the policy ramifications of the approaches available in the marketplace and where we can be helpful to stimulate the growth in the marketplace and the adoption of health information exchange to secure a reliable, robust fashion. I think it is a challenge for all of us to keep our discussions at a level that many of us on the committee are not highly technical can understand in the best informed to make policy recommendations to ONC and others. I hope you will help us understand this in context.
To do that today, Doug I think will set us up with some of the background information. Why don't you go ahead and do that.
Thank you very much. I just want to welcome everyone and thank you for participating and for all the feedback we have received. I think the first thing is that I want to make sure we frame of our discussion and continue to make sure that we move in a direction that will be helpful to support meaningful use and health-care information. Our initial charge to this group was to create a set of recommendations that would allow the Internet to be used for the secure standards of basic change of health information in a way that is both open to all and fosters innovation. I think this is the second of the meetings that we have had that is trying to understand and get feedback about the policy and the technical framework that will allow that to occur. The reason for this is that much of the work in meaningful use in the criteria that has recently been made publicly available the last week requires the exchange of health information among providers and with patients. In taking a look at those things, it is clear that one of the foundations to this exchange of information is the ability of the doctor or a laboratory to be able to send information from one place to another. This notion of being able to take the information, push it out there so someone else can receive it. So, it seems like the exchange for treatment or payment purposes sometimes -- Well, I should say with regard to meaningful use, what we do know is that oftentimes this is going to be something that falls under treatments for payment purposes. Usually, you are going to know the person on the other end. You know, to a particular person or to a particular pharmacy. Although, in some cases there may be prior relationships. If it is a new consultation or in new prescription. The center may not have a prior relationship. We want to make sure we understand how the technical and policy framework can help support these kinds of functions. If we think about the Nationwide Health Information Network, we have reviewed this in some of the previous meetings, but there are sort of six foundation components. We talk about vocabulary, document, and message standards. Many of these have been articulated in the recent standards IFR. The last meeting we talked a bit about directories and how those can support this. I will spend a little time reviewing some of the recommendations and the discussions we have had at the last meetings.
Today our focus is going to be on authentication and certificates. We also recognize that delivery protocols, security, trust relationships are also important components and clearly will be touched upon, I hope, in the discussions today since authentication and certificates clearly involve some of those things. I think it is important to recognize that the work that is going on here is part of an evolutionary path that we are moving incrementally toward the goals that we have for 2015. We are starting out trying to make sure that we start incrementally and can build on that. Part of the discussion is, how can we take something and simplify it to make sure we can meet the goals of meaningful use but still with a look toward the future? This gives you a sense that in 2011 we want laboratory results in ePrescribing. Incrementally, as the years go up, we will get additional recommendations from the HIT committee that will include additional kinds of the data exchange. By 2015, we hope that there will be access to comprehensive patient data and the ability to do realtime surveillance. We will be working, I think, very closely with this committee and the policy community to help us achieve those goals. With regards to the findings, I have just a couple of ballpoints here that could was an attempt to summarize some of the discussion we had at the last meeting. What we found is that there are extensive provider directories out there, but there are a lot of different business models in which they are created. It is not particularly clear that all of those are vying to be sufficient -- all of those are going to be sufficient. A different directories have different kinds of data. There is different levels of accuracy depending on the use and sort of the incentives for keeping them current. Different definitions of data exist. And there are certain kinds of data that may be needed that may not currently be collected.
Incentives must be sufficient to get the data needed for the particular purpose. But we want to make sure that the use and necessity meets the appropriate checks and balances. That is going to be an important aspect to try to make sure that the data that people are using is accurate and is able to support those needs. We also heard that the private sector and government programs that rely on directories will still need to maintain and operationally support those directories for the purposes that they have been initially set up to do. As a result, there is likely the need for policy standards and governance. In order to expand the exchange of collaboration and help those directories support the meaningful use criteria that has been identified by the policy committee. We also have to be cognizant that patient confidentiality and security are important, because directory services, if I am properly setup an offer, it may increase the risk of identity theft. We need to think very carefully about making sure that that information with in the directory is adequately protected and safeguards exist for that information. Finally, we heard that there's a lot of different approaches that could be explored as part of our work going forward. These include having the federal government serve in a coordination role, perhaps setting up standards for a set of core data elements, creating authoritative directories or directors of directory, certification based on policies for data accuracy or timeliness -- and these are the things that need to be explored. I do not think any of these have been decided upon. We, certainly, are going to be looking to this committee to help us with some of beestings.
Today the goal is relate the focus of authentication. The question is, what can we do today to accelerate Information Exchange under a variety of different scenarios? What are the issues related to authentication that can help accelerate that? In supporting your term of functionality as well as some of the broader NHIN query functionality is, we need to focus on the need for authenticated entities, individuals, or organizations. There are lots of different models to think about. One is sort of aid allocated one in which an organization maintains it. One could be at the individual or provider level. This would be an opportunity to discuss different authentication models and get some testimony from folks about what has been done within federal partners as well as within the private sector. Other considerations for the committee include the need for what we call a solid trust fabric, the ability to sort of have trust as part of the exchange of this data. We hope you can provide us some clarity of from the best role the government can serve in this. At the end of the day, we wish to enable broad participation across the spectrum of organizations from both very small organizations to large ones as well. With that, I am going to go back to the agenda. We have testimony, I guess, next from Dave. I no. Has he -- okay. He is on his way. I will turn it over back to David.
All right. Just one other comment comes to mind with your presentation. I think a number of us understand that the ark of time that Doug described, the scope of authentication requirements or the scope of the [ indiscernible ] will grow from the inner circle, if you like, of eligible professionals and maybe the immediate participants in meaningful use. I think as we are finding the problems at this stage, primarily there is one of provider to provider data exchange, the purposes of 2011 and so on. We know that in 2013 and 2015 and beyond, there is a much larger number of much well organized you users will be interested in sharing information across the network. To that end, I hope he will help us understand where there are solutions or policy issues that you've worked on and addressed that speak to this professional data exchange. Are they going to be extensible and scalable to the general issues in the population, or do we need to be thinking about a road map that accommodates much larger set of issues as you think about the whole population being users on the network? We do not want to solve the problem today, but we also do not want to close off doors that will get us there in the next four to six years. While we are waiting for David to be available, I wonder if any of the committee members who are listening to the presentation have been pondering this and have any other comments or questions you want to surface for us or for the witnesses today. Those of you participating on the federal panel, are you available now? We could get started. I would ask you both to take a second to introduce yourself and maybe a moment of your background and roll. Also, if you could make an effort to eliminate your verbal comments to no more than five minutes so we can have time for discussion with the whole group. Thanks very much, all of you, for coming. Why don't we start with David first. Do you might introducing yourself and just jumping in?
Thank you. I would like to send the health IT policy committee and the working group for inviting us to submit testimony as well as inviting us to make comments here this morning. I am David. I am the director of federal identity management for the GSA Office of government-wide policy. We are charged with providing the federal government with how we as identity providers manage identities for individuals accessing our systems and facilities and also how we authenticate the public for our electronic purposes and for our businesses in the federal government. You have testimony from Juditha from my office in your packet. I will be addressing some additional comments. I would like to elaborate a little bit beyond the responses to the questions in the testimony for our mission and how we have gone about it. Our mission for the federal government I think is not dissimilar to the mission facing this working group as well as the policy committee. We were charged with providing for common infrastructure for the authentication of our internal people, business is coming to do business transactions with the federal government, as well as the public. The U.S. National Public and International in. Individuals, businesses, and organizations axes are protected resources in an on-line process, conduct transactions with us, and support our electronic government applications in the federal government where authentication was necessary, where it was necessary to know what it was on the other side of the transaction coming in. We have been charged with this since 2001. My office and the General Services Administration inside this mission. I would like to make a couple points about how we have gone about that for the federal government, which I hope will have relevance to the working group.
First of all, our infrastructure is based on a common policy framework in the federal government, both my office, Office of government-wide policy, Office of Management and Budget, and most recently under the CIO Council. As they called the subcommittee under the CIO Council and have the responsibility for issuing government-wide policies for how we do authentication. I am not going to go into all those policies, but I would like to mention three key principles. First of all, you may hear mention throughout this morning of the federal government's policy for authentication levels of insurance. In 2004, we with the Office Management and Budget issued what is called OMB policy for 04. What that said was there was not just one way to do authentication with one strength, but we defined for levels of authentication assurance based on the risk associated with the access to the resources or assets or the transactions that is being performed the final level authentication that is necessary and tying those to the 45 policy levels. Secondly, our policy was built around that we would leverage identity credentials and identity management practices outside the federal government. We were not going to be issuing national IDs or its to everyone and everyone in every business, but rather we will leverage the infrastructure that already exists in different communities. The third key policy point on that in leveraging that was that we must be able to trust the identity management practices of other organizations and have the means to establish that trust. And we must ensure that the authentication process of organizations we would be using outside the federal government or across the federal government are interoperable in how we exchange data, process that, and the definition of that data which are used for identity and authentication assurance.
In order to implement the policies of the federal government, our identity management policies, we look to standards, industry based standards, for both technologies as well as the protocols. We want to use mature technologies. This will not be a technology discussion, but we have adopted a number of authentication technologies as well as protocols. When we adopt those Technologies and protocols for federal government use, we then do is define exactly how data will be arranged, what that data is come in how it will be transferred. Whether it is across devices, components, or systems. Specifications for the government use of industry standards to implement our are put into place. Consider those interface specifications for how data is exchanged. Without that, we cannot have interoperability. A the third point I want to make on our program the third point I want to make on our program is about trust. In order to insure that entities within the federal government who are issuing IDs or identity credentials and managing identities, we build a standard Trust model. That standard Trust model is based on the four levels of assurance from the 404. And that level of assurance we ask our friends at the National Institute of Standards and Technology to elaborate on the policies for those of four levels of insurance assurance. They did in special publication 800.63. It if technically and from a process standpoint, it is how entities would conform to our policy requirements for levels of insurance. We take those requirements from the National Institute of Standards and technology and build evaluation procedures for different protocols both for how we manage identities in the federal government but also how external entities that want to interact and enter operate with us in the federal government and be trusted can be evaluated. We established committees within the federal government provided that evaluation and approval process.
We end up with trusted entities within the federal government, trusted entities outside the federal government that have been evaluated to conform to both our trust requirements as well as to conform to our interoperability requirements for the profiles that we have written. The last point I want to make on our program is I have described what the federal government has done in establishing the program for policy based framework and become a standard industry and implementations, the trust model for evaluating identity providers within the government and outside as well as how we determine conformance with interoperability requirements for any protocols. At the last point I want to make is, we have defined additional roles for industry. This is not exclusively the federal government that does this. Certainly, establishing policies is the federal government role. When we look at how trust can be generated and evaluating identity providers against established criteria, that is not necessarily a federal government role. We have encouraged industry to build the capability to provide that a function both for us in the federal government so we can trust industry based providers or commercial providers or other organizations but also how that same framework can be extended beyond the federal government for other purposes as well, for other communities. Whether those communities be health care, emergency responders, or higher education. In that way, there is value to both us in the federal government for our electronic government program and the functions we perform, for the providers themselves in expanding the scope of their trust, as well as for the users of those communities in building a trust framework that they can use their credentials, their processes for both external use and internal use for us in the federal government. I am happy to take questions at the end of the panel. We will turn to the next panelist.
Thanks very much.
Good morning. I am to him from the National Institute of Standards and technology. I am pleased to be allowed to come, and thank you for the invitation so I can give you a mixed view on authentication. I apologize. We did not -- we have some competing interests going on at the shop right now, and we did that have time to get written testimony together. I would ask your indulgence to give me a couple extra minutes, because there are two specific efforts I would like to describe. I think they will be of interest to you. I think I was getting OMB time as well. First, our authority is limited to non national security systems, federal agencies, federal data. That is the scope of our authority. However, I should say that adoption or convergence -- adoption by or convergence with private industry is a key metric of our success. When we build standards that no one else wants to adopt, we know we have not done them very well. So, there is a difference between where our scope of authority is and the scope that we hope to address in our efforts. Authentication I think as David already alluded to in our view is a life cycle. If is not just a protocol or mechanism. It begins with determining who someone is when you establish them as part of the authentication system, tracking them and removing from the system when you should. It is not just a protocol of the bits running on the wire. With the two efforts I am blind to talk about -- efforts I am going to talk about, they are focused on identifying who the person is not at all with authorization. When I looked at some of the definitions that this work group may have adopted for authentication, they may be broader than what we have looked at.
We certainly draw the line in both of these efforts before the authorization step. It we see authentication as being the foundational element. If we cannot know where you are, how can we decide whether or not you should have access to data? But the efforts I am talking about leave authorization as a local decision. This is to give you the information upon which to make that decision but to go no further. As I said, there are thank you very different efforts that I want to talk about. They come from trying to solve a very different problems. The first one that I would like to talk about is already mentioned. 863 work, which is actually responsive to zero and B 0four 0four. There was an establishment of four different assurance levels. There was a requirement placed upon this to go and write technical guidance on how to implement and achieve those four different assurance levels. So, the interesting thing about 863 is that because we are trying to solve a very great range of problems in depth from the lowest level where all we want to do is be sure we are tracking the same individual, we really have no idea who they are, to one where we have very high assurance. We could not prescribe exactly and architecture. That document is more of a framework. It is built, for example, a to permit delicate and authentication but certainly does not require such a model. Many of the techniques described in 863 permit the use or might even require the use of directory services, but there are others that would be completely independent. 863 was designed with the idea that we want to be able to authenticate using whatever credentials they may already have in place. We are looking for ways to leverage those kinds of credentials. , not necessarily mandate that these credentials be issued by or directly on behalf of the federal government.
So, that is a very broad range of trust problems. The second effort I want to talk about is 6201. The verification credential was specifically targeted to be responsive to homeland's security presidential directive 12, which has the goal of being able to strongly identified government employees and government contractors. In this case, it made sense that this is one to be a credential issued either by or on behalf of the federal government. We were able to take a much more tight leave prescriptive approach and be able to specify the technologies and actually target particular levels of assurance we want to get with different aspects of the credential. That is a case where we actually require directory services to support certain parts of that. It is also a place where the delegated authentication model of some federal agencies should be able to authenticate credentials that come from other federal agencies. So, that kind of is a quick and broad overview of what we are doing. One thing I would like to add to that is that in one of the more slowly roll outs, unfortunately, of all time, we are working on a revision to 863. 863 was originally written to be very prescriptive and make it easy for federal agencies to implement or to limit their choices. There is a. Off between giving choices and being easy to implement. The initial versions of 863 were intended to take the mystery out of the process but not permit all possible authentication mechanisms to be employed.
Based on the feedback we have received from industry and from agencies, we have been working to broaden that approach and provide more flexibility to agencies in meeting the mandates for OMB 0404. There is a second public draft that will be coming out. I certainly hope it will be this month. I really hope it will be next month if it is not this month. But we are working to move that way. It has been a very difficult problem to walk a tight rope of making this accessible and implement the bull by agencies and yet not overly concerned. There are versions of that document already out there. We continue to try to improve that. Hopefully, that will be available to you in the next month or so.
Thanks a very much.
Good morning. It is a pleasure to come to the Mayflower first thing in the morning and get warm. Someplace blocked from the Metro stop is always welcome. You've heard from my colleagues. These are highly valued colleagues that we have worked together for many years. You have got mine written responses to the questions, so I do not want to rehash that. But I do want to make a couple of points. The first point is that the questions and issues which you are concerned with are not new. The questions and issues you are concerned with have been here for many years both with in the private sector and the federal government. Within the federal government starting in 1998, I have been involved with the activities related to solving these problems. They were going on many years before I showed up. These have been addressed in the technology policy and practice dimensions. Solutions have been in place both the policy level and the practice Lovell. As David mentioned, the technology level. They have been in production for several years. Therefore, I do believe and strongly encourage you to not create anything new, to not ignore what has gone before us, but to fully and former selves with the existing environment that is critical to your success in both the short and long terms. One of the reasons it is very informed is because the fundamental conceptual model of relying on credentials issued by other entities at unknown assurance Los is fundamental -- assurance levels is fundamental. It links your applications to other credentials. It works on a baseline of mutually agreed upon trust.
Not only is this something operational within the government from both perspectives of credentials issued but it also has been widely adopted in the commercial and private sector. We have a very strong, long-term relationships with many of the credential providers, the technology providers, the credentials implements, and the Software solution providers to run and build software applications on behalf of the federal government. Many of our partners and colleagues in the private sector are behind us today. They can testify to the success of knowing what to build to in order to have successful products and services provided in the marketplace. The goal has been to do together what we cannot do separately. Rely on credentials issued by others at no level of assurance using all available technologies. That is what David's Program has been all about. That is what Tim's practices have been all about. When it comes to the National institutes of Health, which I am happy to be a long-term [ indiscernible ], we have implemented the trusting party piece of that very aggressively. We are capable of and in production today relying on credentials issued by many different parties at a known assurance levels. We have tens of thousands of university credentials coming to us to access NIH electronically. We are able to validate them and pass issuance level and the identity credential to the relying application. NIH library is a classic example. Only one of them is coming on line. We will be able to do electronic in a much more robust fashion very soon.
There are, certainly within the federal government, upwards of 20 million employees including the military and in-house contractors that have high insurance compliant credentials. I have them in my pocket. It blows 1I turn off the lights. We are able to use that to access [ indiscernible ]. I can get into the mouse labs and not been tested. That is exciting. Also, to authenticate to my Electronic infrastructure, to my network, to my electronic personnel folder, to my travel system, to my email. These are very important high risk, high assurance activities. The credentials, the high insurance credential, allows us to do that. I would assure you that -- Well, my partners will speak for themselves. I assure you that this is high assurance. We know what your DNA is and where you parked your car. That is not necessary for all applications, perhaps not even most. Frankly, I don't think -- I don't know how urgent it is for everybody to know it is a high level of assurance that I am wondering the mouse labs, but there it is. There are solutions in production now at all insurance levels, one, thank you, three, and four, using a wide variety of technologies. The open ID solution, in full card, digital certificates, onetime passwords. We have all of these in operation in production. Clearly, the model that the government has put together has been a model that we have been able to use. Thank you.
Thank you all very much. Let me turn to our panel and those of you on the phone. We want to check in for committee members on the phone, I think Mark may have joined us. Anyone else on the phone? What my ask my colleagues if they have questions of the panel. Okay.
I have a number of questions. One just relating to the last point you made. If you can testify as to levels of assurance inflation. That is the notion that everyone believes there need is slightly higher than everybody else's need and how you were able to or if you were able to get a downgraded Lovell of assurance.
Well, after some raids from some rights organizations, we felt that was something we needed to protect a little more. Fundamentally, the guidance of 0404 is paramount for us in the federal government. Broadly speaking, the principle of using or applying a standardized risk assessment methodology to your online application is what turns out your assurance Global. Federal government has a standardized high-technology. It has been on and off in revision for a while, but it is a really solid place to be. If you have an application you want to put on line or you have a system of applications you want to put on line, it is incumbent upon you and is mandated in the federal government that you do a standardized risk assessment. One of the outcomes of that standardize risk assessment is the information about what assurance levels you need for various roles. If I'm just a user of the system, I only may need a level two credential to access it, but if I am actually going to change data, that changes level.
Adjust to like -- I would just like to elaborate on Peter's response. Our mission was to be a will to provide the authentication tool and infrastructure at four levels of assurance. The decisions for authorization based on whatever level authentication is determined needed by the owner of that application is there decision. We did not try to standardize that or dictate that. But to allow the tools based on RISC based decisions. Peter mentioned tools that we provided to allow the determination of the risk and vulnerability for the online applications. But the decisions for what level of assurance was necessary for authentication was the application owners.
If I could add one thing to that. The real importance of using the tools is that there are too many mistakes that people will make if they don't rely on the tools and work -- you know, do the message for risk management, risk assessment, to determine the level. The first one is everyone believes what they work on is very important. They all believe in it must be level four. That is the first reaction that we sometimes get. The second reaction you sometimes get is, I already know what technology I want to use for authentication. So, my risk assessment has to come out at level X, because that is the highest level that might technology will permit. So, if you let either of those overriding concern said the real you, you will either spend too much for authentication because you did not need Lovell four, or you will not get the security you need and will be sorry further down the road because you came into it with a decision made up front. As Peter was saying, running the tools, there is a lot of background and history. Relying on those is extremely important to get it right here.
The second question I have relates to the point that you just made, which is that costs and utilization trade-off between levels of authentication, that is -- first of all come any day that you have on the cost. Off, but also in areas where the utilization of the system is quality voluntary. Whether you have done any research to the utilization. Off of the upper levels of authentication. The reason I ask is there is a trade-off between making the system easy to use so we get more information sharing and require higher levels of authentication that may end up putting barriers into place.
From the point -- let me take this one. From the point of the view of 863, a utilization was not actually in -- it was strictly risk security. Can we achieve this well below the assurance -- achieve this level of assurance? We recognize it was voluntary to adopt them. We have really searched, especially in the revisions here, for ways to incorporate more cost-effective, more user friendly technologies. It is a really hard problem. As the security requirements and the assurance requirements go up, everything else goes up. It is very difficult not to make those higher levels become more difficult. Now, utilization might be something that you can choose to factor in in terms of your own decisions. It was not something that was -- It wasn't a degree of freedom that we have from OMB 0404, but it certainly is a factor in whether or not some of these projects are successful. We have had the luxury with something like 5201, and it was not an option in the process.
I would like to elaborate a little bit on Tim's response. As with any security mechanism, when we define levels of assurance as the security level or the insurance level increases, thus cost of the security mechanisms will increase. For what we did for the federal government in response to homeland's security presidential directive 12 and what has been 5201, the standard for a standard government ID and howl is embedded, we define the highest level of security. We also allowed in use cases lower levels of authentication if that is using that card and credential if that is what the application owner needs. Nevertheless, there is certainly a cost. There is a cost to the infrastructure and the use of credentials that are facing your working group. I would like to reiterate the point that Peter made. By establishing common policies and standards across the federal government, what that does is organize the market so developers and service providers -- product developers and service providers are developing products and services to conform to a common set of requirements. Not many different requirements at a cost to the developers and it cost to the consumers but common requirements that both meat and conform and maybe exceed our security. And that organization of the market becomes very important as a look at communities that are adopting a high level of security that we have defined under 5201 for their own credential Lange, recognizing that that is market driven and we are driving both the security level but also the cost structure. The ongoing delivery of those products and services as we go forward.
We have not yet seen a use case in this space. We have talked with many of the government-wide colleagues. We have not yet seen a use case where we don't see what happens around the table and being able to find a cost-effective, user friendly solution. The.
Could I add one last point? I just realized something. There was something important about utilization I should have noted. When you factor in utilization, part of the question will be, is the person opting in also the person whose data is being protected? In the case where we want the doctor to utilize the system but yet the data we are protecting is the patient's -- again, it is a tricky question. It is one that we are very happy we did not have to address. It is something I would like you to keep in mind if you decide to factor to keep that in.
I want to get to the issue that you all kind of raised as the necessity, which is the reliance on third parties. There is no way to make the system work unless you put a strap on existing credentials. Let's shift to the issue of the oversight mechanism to make that work. I know there are documents that is sort of the ongoing monitoring policy, but I am interested in particular if you could elaborate for us and help us understand how you do this in a more detailed way. In other words, are these third party is observable in any way across the network? What is the policy around audit and redress and some of these issues? I think it is one thing to say we have a certain set of criteria and we will test to make sure we can do this the first time, but it is another thing if you want to maintain trust to police across the network in an ongoing way and make sure that any inconsistencies are observable to anyone relying on that framework.
Okay. We all look at each other and say, wow. In fact, the federal government has a very robust program in place that does this. It kind of works in General Services administration. Is the actual effort there. It is the federal policy authority, which not only evaluates the policies and practices from business and technical of high assurance providers that want their credentials to be utilized in the federal space. That requires an annual audit. The government gets an annual report on whether or not the credential provider is living up to the policies and practices that have been assessed by the government. That is a very rigorous and robust and Frank, frankly expensive process. That is where the cryptographic credentials are price levels one and two, the requirements for oversight and audit still exist. Because local one credentials are basically little or no assurance of identity, the audit requirements and assessment requirements are much less progress. Level two, they become more lip rigorous. O Level three, they become substantial. Level four, they become almost owners. So, there is a varying degree of review depending upon the trustworthiness of the credentials by definition. At 01, there is no real requirement for audit, but there is a real requirement -- you could speak to this better. GSA has a program that assesses potential providers and trust framework providers. There is a standard methodology. It is published in has been reviewed. It has been blessed by the federal CIO council. That practice, that methodology, describes how the federal government assesses candidates who want their credentials to be trusted and utilize to at several sites. That is in production. That has been in place for well over a year and a half now at 01, Level two, level three and of course level four. They have been operational very successfully since 2001. As David mentioned, we have had a strong impact on market at all assurance levels. I also want to say that the methodology addresses questions of privacy so that not only do we want to be concerned about the trust will will of the credentials we are seeing from external providers but we want to know about their privacy practices. We want to make sure that they conform with minimal government comparable privacy practices with relation to the individuals who are using their credentials.
Can you provide a little more insight on my strategic -- why strategically we did this? That determination of trust and an external third party's identity management practices, how that trust determination is made becomes very important. We determined in the federal government to centralize that evaluation process in my agency as well as committee structure where we do that evaluation process. If we did not do that, each agency would be out to make those determinations on their own obtaining whatever policy documents or procedural documents or maybe audits that may be performed. Attempting to go through that and determined that this is an entity we can trust. We felt is much more affected for the federal government to centralize that function and public depots to the evaluation procedures, requirements, and how we go about that process as well as the entities we have approved. Other communities outside the federal government -- but so communities outside the federal government could see our process. If they trust what we have done, they could accept our trust determinations. I think it becomes very important in considering how that trust is built to a point that I made in my comments. We are encouraging industry to perform some of those roles. We publicly post our requirements, our criteria. In fact, we publish documents for Hall industry could actually make those determinations, those assessments, and demonstrate to us their process of federation trust providers for how those determinations could be made so we could rely on determinations made within that community by an entity that has the authority to make evaluations and make determinations with the idea that we don't have to go out and evaluate every one. It would benefit across both government and industry groups to common practices and a common trust model that we would like it to be the common trust model we built for the government because that is our policy basis.
I just want to ask a follow-up question. I understand that piece of it, but is it true that the way the third parties performance those requirements it is observable across the parties and is any consistency observable across those parties? In other words, if you want to establish a cross across a network, it is important to let other parties know that we initially evaluated and entrusted the partner. We have had some experience that indicates that that may not hold true any longer.
Certainly, the higher assurance level is an annual independent audit of practice. Com, which does catch that stuff. There are -- I do not want to make bad jokes about audit firms, but, in fact, we rely on the reports of independent auditors to review the practices of high insurance credential providers. They are required to report to the federal government annually. We have a very good review with that. At the lower assurance levels were the risks are lower, the audit requirements are less strict, but they do exist. Even at Level one, there are requirements for annual reports on operations and practices. Where we get reports of problems from either individuals relying on a party, software people that said I used this credential and blue up, we have mechanisms in place in our memorandum of agreement with credential providers for the Federation of credential providers to request review and information about what is going on so we can export challenges when they are brought to our attention.
We have about ten minutes left. I would like to see if we could move on. A couple people hacking some more questions.
What is the minimum that this work group needs to do to enable a million health providers across America and across a variety of settings to be able to engage in secure, authenticated health information exchange?
I can't you heard a consistent message from the panelists and that we have described the federal government identity management program on how trust and leveraging third party credentials have been implemented in the federal government. The minimum that they would recommend is the work group familiarize yourself with the models that we of discussed and bring that to the office of the national coordinator.
I was looking for something a little stronger than that.
Clearly. I would say based on what we have seen, one of the things that is paramount to your charge is that the citizens who are in this system or who will be in this system will be able to trust it with their medical records, trust it with their personal information. So, it is extremely important that this process, that this system that you are considering be trusted by the people who have to use it. In order to do that, there are standards and guidances already in place. Privacy Act is a good model. Privacy Act says, if you are going to exchange personally identifiable information electronically, you have to protect it at the OMB level three. There are a number of technological solutions to doing that. They are also very by requirements for implementation practices. It is not just about whether it is a onetime password or PKI, but it is about how you employment. Level three allow us a great deal of flexibility in how you employment. I would strongly encourage this committee to accept nothing less than level three.
I have a follow up. A couple quick things and would like to add to that. One thing is although -- just to reiterate. And it is probably not what you want to hear. Because of your aggressive schedule, I was looking at what the time line was for the different applications you want to have online in 2011, 2013, and 2015. It is essential that you go for refinement of what exists rather than an invention of something new. So, I think that is going to be important. Another piece is, even in that short time, my experience from 800-63 is that technology moves fast. Rather than focusing on what the technology should be, I believe that focusing on what are the real risk levels is probably the most important thing to do, and then maintain your technology independence. The one last piece is that what I think we have found in the past is that people want to drive an entire system up to the high watermark of the well of assurance. It is frequently true that you could build a system where many of the users can work at a lower level of assurance and only certain things have to move to the highest level of assurance. Avoid the drawknife, as we mentioned before, of the inflation points and try to break out applications into buckets rather than one size fits all. I think that would be very important to the success.
Let me try this out on you. What you are saying in more of a politick way than you are prone to speaking, is what you are saying to us, what you have to do is you have to either announce or put in place a process for stating what the level of assurance is for various roles and use cases for the National Health Information Network or for anyone else who wanted to do this, whether it is whatever railroad that wants to do this. It doesn't matter. Figure out what the level of assurance is, state it, and then anyone who wants to participate would go to any provider of credentials and a convenient way might be those accredited by the government on your list of being able to provide those assurances levels. And then you are done.
I would claim that from what you have said, the one thing is that even within health care, there will be applications to have a range of level of assurance. Driving this all to one level of assurance will force you to the high end. So, it may be that there are -- It may or may not be that there are no applications that would match up to what OMB 0404 calls will one. There may be times where you only care to know that it is the same patient and you don't care who it is. There'll be some range of levels. What is important is that regardless of white shoes as my health care provider or who is my insurance providers that they use the same metrics to determine how to protect my information. And they do the same risk assessment. You do want that continuity. I do not want to have to ask 1I am going to doctor, do you use that message of determining how to protect my data or some other method? I think it is important to bring some --
But in terms of what I said, our job is to set in place a process to determine the level and then telling folks, go find a provider that will do that level of assurance and it is part of a larger accreditation.
Part of your mission is to accelerate the process. That would accelerate the process. And then the implementation.
Thank you. We have Ralph and gym and then we will be out of time. We will try to come back to David Riley.
Thanks. I want to thank you for getting down to brass tacks and talk about how many people are already doing this. I heard tens of thousands of people in The University environment, is that right? We're talking about a challenge as far as I have noted that is roughly a million people. Most of them -- certainly, the majority of them working in organizations that have the confidence of corner grocery store. Therefore, I need to understand a little bit more. I get confused by the different organizations that we have talked about this morning. There is the organization where people work and presumably get their IT service from. There is the organization that issues the credential, and then there is -- which may or may not be the same. And then there is the organization that uses the potential. It relies on the credential in order to grant access to summary source. So, sort of the non mechanical, forget that stuff. If I know that this is Dr. Smith, what do I need to know about the place that Dr. Smith works in order to grant a level of assurance? Do I need to know anything about the security practices? Do I need to know about their employment practices? Do you expect the credential issuer to have ascertained that about the organization before issuing the credential?
Let me speak from the point of view of SP 800-63. We do not make assumptions about, you know, whether or not your desktop system runs anti virus software or whatever. Those things are considered to be out of scope and really something that cannot be verified. And they are left out of it. That is why what you will find is that as blood levels of assurance move up, we rely on -- levels of assurance move up, we rely on credential form factors that are separate from that system or that laptops that that person uses. The protocols that are used is something we didn't really talk about, but also they become more complex so that they, basically, provide a secure channel between a device that is being used to authenticate and what we call the relying party who is trusting the credential. So, it becomes less about the facility where they work. That is not something that we really think is probably -- you know, accrediting the IT shop at every small Doctor's office is probably not doable. However --
[ speaker/audio faint and unclear ]
At level four, we actually have very strong requirements that you use, hard work credentials and things. There are some problems we cannot solve in the standards. The fact that the IT shop may not be very good is one that we report on. The idea about whether or not -- the credential provider, will put much stronger credentials on. Is in fact that IT shop is not very strong, we do not want them issuing the credentials. We want you to go to a third-party provider makes it their business to do this and do it well. So, the design of things like 800-63 was designed to move that or to remove that question or simply not to rely on the answer of whether or not that local IT shop -- you know, what level of quality is there.
Just to make sure I understood, . Your approach for at least up to level three authentication is to use technologies that are relatively immune to pour security practices in the system where the authentication occurs. It is irrelevant.
No, I think what we would say is that as all levels of assurance are increased, we are using technologies that provide greater protection even in the face of some of those threats. At the lower levels, we certainly would make no claim that someone whose computer has been taken over is in any way protected against their private information or losing their authentication credentials. It is a risk we are actually willing to take.
Just to confirm, we have been talking about the policy necessary to be sure of the authentication of the person.
It is all about the ramifications if information is disclosed. We are certainly thinking about those ramifications when we determine which mechanisms are acceptable at which levels.
One last question.
One -- we have to have the doctors' offices practice at this level?
Those are separable issues. I recommended level three for protection of personally identifiable information. If you are a doctor in spearfish, Montana and all of the IT you have is a couple desktop machines and a laptop, we are not looking at how you operate those machines and whether you do anti virus. We are not looking at that. What we're looking at is an electronic credential at 03, some technology issued in accordance with policies and practices. It has been issued by an issuer who conforms to policies and practices that align with 800-63 and 0404. That is all we are saying. Some of the issues you are touching on a think have to do with attributes of certain individuals, and that is a whole other panel presentation. I would be happy to come back.
But just to point out on the rules, if we identified the role of an identity provider and it issues a credential in a relying party, we centrally evaluate the identity providers. Part of that at a higher level of assurance is how they assure that the end users are using the credentials properly. That includes protecting the credentials. At that determination that our relying parties can entrust, and then they can go through a vetting evaluation process from the federal government so that that identity provider can be trusted and the users of that identity provider and their credentials can, therefore, can be trusted.
Does that imply then that someone who is certified to issue a level three authentication would have to go to spearfish, Montana and visit the doctor to see how he is doing?
800-63, if we use
That promotes authentication through levels three, and that puts a number of additional requirements for a number of other things like postal delivery and things like that. It doesn't allow instant gratification, but we don't mandate that either it's the doctor leaves spearfish or anyone go to spearfish until you reach level four.
So if you would see how they used credentials and how they kept track of it as opposed to how they got it in the first place. I wonder if that requires a visit to Spearfish.
There is no sense in going through the country and checking that out.
We will have to come back to that later.
I have a quick question, related to something you said, David. The talk about GSA 's relationship with businesses, obviously for contacting purposes, and I am wondering if those relationships from an authentication standpoint, are they organizational-level? Is there a Model that supports organizational-level authentication, with a trusted organization?
Let me explain that.
There are product developers and manufacturers that are used in authentication systems. One of the things we can do is approved the products that conform to our specifications and can be used. There are service entities that are contractors that do the work, could be those entities, and organizational entities that do their own credential and within that organization or they oversee a credentialing process, calling the identity of rules much like that.
We approved contractors and contractor products as and service providers Port government-wide use, but those lists are publicly available, and we also approve not only under contracts but also under our identity management. We approved entities that have conformed to our policies as an identity provider, as well as organizations that could do the work to evaluate identity providers, and determine their trustworthiness at a given level of assurance and conformance with our policies. We call those batteries and trust providers.
Yes. In a federated Model though, the trust relationship still assumes that those individual identities are authenticated.
And the level of assurance that the credentials are issued two. Each level of assurance is a level of authentication assurance.
I will ask if anyone on the phone has any other questions before we wrap up this session?
All right, then we thank you all for taking the time to join as. I am sure that we'll talk more.
We might take just a minute and see if David Riley is available to go back to the opening presentation which we skipped over, and maybe we could compress it into a few minutes beings that we are a little behind on time. It has been a tough morning, Iniki for being here. Passed on a few of the things in remarks.
I have asked three slights, and I think we could keep a fairly short unless there are a lot of questions.
If you could jump to the first slide?
What I was asked to do was give a little bit of background about the authentication within the NIHN and what we have done last few years. And I think it is important to articulate the last couple of principles in the process in terms of the messaging, security and privacy security per services that we have to find so far. And two of those I have listed here.
The way we articulate the local accountability principle is, there are two aspects to it because there are centers and receivers for the health information exchange. And basically the local autonomy principal says that the decision to release information as a local decision because care is local and between the provider and the patient, so people that have the basis for the release of information or at the local level, we basically deferred any decisions for the release of information to that level.
And that is a choice within your organization, whatever form it happens to take, that authentication levels are within the organization as well. So it is based upon their risk analysis to determine what two risk is in the application that uses that information and the users that have access to those applications to determine what level of authentication is required for individual users to be able to access that application and that data.
In terms of the local accountability principle, basically what this says is, whenever you make any assertions about authentication or identity it about an information exchange whether you are a center or receiver of information, you will warrant that those surgeons are true and correct.
You will have a number of requirements with respect to a syndications, and I have tried to list them here and on the falling slide, but the basic assumption is that authentication is necessary to facilitate trust and information exchange. We have taken that as a given and sometimes it doesn't get articulated clearly up front so or not it would be useful to articulate it clearly at this point.
The second point here is that the level of authentication may vary depending upon the type of information involved in the exchange and again, this is based on the risk and the assessment determines whatever level of damage should occur if there should be a breach of that particular form of information. The third point is that the participants are authenticated, and these participants may be devices like systems or gateways or servers or processes on the machine, or they may actually be people that our users of systems. Bald of these require some form of authentication League are involved in the trusted exchange.
Certain types of exchange may require consumer authentication. I noticed that we had some testimony scheduled from Sean I think from Microsoft and he has a specific interests in consumer authentication and how we go about doing that, so we recognize that if we expand all of these cases that are that scope of NIH, consumer authentication is something we will need to address this next year.
Finally on the last slide, we believe to insert Interoperability of authentication, there must be a standard for communicating the authentication approach. What are assumption was when we built the authorization framework for the NIHN was applying the local autonomy principle. We would say, it is your decision how authenticate this individual, but if you are one to make the request of an organization to send a copy of a record, you need to be able to assert certain things about that individuals of the receiving organization has enough information to be able to make a decision about the release of that information based on a local parlance, policies and preferences set up on the organization. So the local accountability and the local autonomy principle will be applied and it allows us to establish a trust fabricant a technical level, where this organization has the autonomy to do what it needs to do to get its work done and make the request, this organization has the right to make a decision based on the data sent across about the requestor and purpose for years and those kinds of things to decide whether two release that information. I think it is important to understand that the Model that we have before thatNIHN note to note exchange, this would be particular organizations whether it be NIH or eight to SP or whatever they happen to be, our idea was that these were requests from information. Not a remote access and the form of a remote log on to some remote application where you are logging onto someone else's system, but instead, these are actual request for information, there is it a decision for a release and information is sent across in the form of a summary record or whatever type of intimation is being requested.
So in this scenario, applying rules and principles we just talked about, we realized early on that we would need to have some free market, some standard for being able to package up data about the requestor so the receiver could make the decisions about that, and I think it is important as we move forward that whatever that Standard and stepping as far as a recommendation from this committee that we have some standard for that metadata that is associated with that request. What we have implemented to date is We're using as a ML as a way to do that and there is authorization and identification and I want go into the boring details of what is in there, but if you are interested we could have a sidebar conversation about it later. Otherwise that summarizes the general context of what we have got for the NIHN. I think you have already heard some of these things that I have articulated and will probably carry them multiple times today.
I have a clarifying question. You heard the conversation the last few questions and it seems to me there is an awful lot of reliance on the intermediary clear to be the vettor of [indiscernible] and I think there is some unease as Wes characterized it [indiscernible] poorly developed as they seem to be in many settings, we have pause as to how Best implement the authentication approach.
How are you thinking about the level of competence and the fact that those intermediate players have to have?
We didn't necessarily assume there had to be an intermediate later. NIHN could be designed as an application that is sitting on an end user devised in order to participate in larger exchanges, in that sense it would be an actual application running on an end user device and meets [indiscernible] from the perspective and that would be incumbent upon whoever built the application to go through the process of implementing this service back and making sure to conform to is testing that they actually meet the requirements.
It also predicates -- I guess their is a requirement that if you are using some sort of third party identity management to issue the credentials, if you would be able to get that credential issued from somewhere else, and enter that into your application so that credential is available as a part of the transactions that would be needed for NIH level transactions. But our assumption was not that there had to be an intermediary. We worked with a lot of those to begin with and overall we realized there may be instances where people would simply have applications that will participate in those kind of exchanges.
Man had a quick question to follow up?
Thank-you, that was helpful. I imagine that I agree with something you said so I wanted to make sure I understood and ask you to talk more about it, and that is that the authentication model is a local decision. I am thinking about in particular, how do you facilitate Interoperability is a physician wants to do it particular application or function on the network that can HIE in Dubuque has said that is able to sing but with a query, that is in trouble for thing. How do you facilitate that, number one, and number two, does it raise a series of trust issues from the consumer perspective, because if my local HIE has a number of problems because the tried to facilitate maximum participation in the exchange by having the levels of authentication, now that is creating a lot of security risk, but if I move next door or 100 balls away, it is different. I'm not sure what I -- that I agree with that.
What we were referring to was the local autonomy -- basically the local organization, you have local law that exists in the state and you may have organizational policies that you have to adhere to. And there may be preferences' set by providers or patience respect to the release of information. Those are all things that occur within the organization. And if that organization was set on all and authentication Lovell also and they decided that that risk is acceptable for those kinds of things that would be involved for EHR or whatever if it happens to be and they make a request for someone else, we have set a framework for the level of -- I am authenticated at Level two, this is my purpose for years, my user ID and session ID and some of those other things. Once it comes here, this organization is not required under law to audit that request. So if I have level three and the sky is asking Ed coming from a level two, it is my decision here as to whether two release that or not.
That is helpful. But I think what I am saying, why should we think about -- I'd think it is worthy of some discussion, but there or not there should be some sort of force that by the government entity of the nationwide Health Network that's just say this application is at least a level to and if you want to make it more or less -- should that be a function for the government of the nationwide network rather than always been the local decision?
And link that was part of what they were picking at a few minutes ago when he was trying to get the guys here to commit to a specific level.
In terms of the work group when working on the NIHN standards, in terms of NIH node to NIH node, it would be -- machine to machine. Wanted a fairly strong authentication method between the gateways if he will. Now in user authentication is a whole different thing that we're working on in terms of how it would transmit -- like say I wanted to encrypt a package and wanted to ensure encryption is done. How do I introduce that into the existing trust fabric and how to route that? Those are active things that we're working on right now, coming up with models as to how we would implement that and support that. But our assumption was that, most of the healthcare applications that we looked at would be either level two or three. You already have a floor in the form of HIPPA, the feds have a floor in the form of FISMA and the requirements they talked about here, and you have some disparities with respect to the process these that have to be in place to ensure assurance in terms of the management of information.
So the question of whether that NIHN government needs to set a particular standard, I think that is something this committee should wrestle with and make a recommendation on. I can tell you that today, it could be a level two or level three, and in some instances, if you are wanting to prescribe narcotics of the network, some people say that we need a level four. And that is a debate that is ongoing and I am not sure that would be settled in time. Certainly it is in the purview of this group to make a recommendation of that group.
Carl has a short clarifying question.
When you say their is a scanned for communicating the authentication approach, is that from a third-party assertion, or is that just one party saying to the other, this is what I am using? Because I worry about the verify ability of that.
What I was getting at here was the envelope that he package around one message saying, a lot like to know if you have his patient and if you do, I look like this record, the metadata in that record was about the requestor and purposeful use and all of that. We have been using the SAML standard for that, and the authorization for a mark for all of that is where that is detailed. It has authentication authorization components to that if you are familiar with SAML. And basically what is going on inside the organization at the age are level, we have been largely unconcerned with a topic ready to make a recommendation outside the organization and at that point the need to be able to populate the SAML position in order for the receiving organizations to be able to process that can become beautiful fashion and talk about the release of information. Does that answer your question?
I just wanted to make sure that I got applicability straight here. At one point, I think I understood and I think it is still true, that the work being done in the NIHN is connecting HIEs and other organizations that for some reason would not want anything between them and the other organizations.
For various kinds of computer to computer transactions, it almost sounded like, any use of identity of the person in that environment is almost for the audit trail. It says, we can tell you who, back in the real world of people users initiated this inquiry or something like a bat. But it is not for the other side of the connection to grant access to an application directly, it is computer to computer.
Let me second that because at least in the way we modeled the transactions, there was not a remote access to the application, it was a request for a record or summary record to be sent. So we are not talking about remote access to anything, you are not looking at somebody's in box. That not the kind of transaction we model. So what we have implemented right now at least in our connect solution of the gateway, there is a policy engine that takes that SAML position and local XACML assertions and the SAML assertion plays a role in that. If I have a policy that says I want relates to anyone that is above a policy level two, and you release it bubble to authentication, then as part of the authentication of those policies that I have locally, it would make a decision not two release that information.
I know that David wants to move on but I have questions Offline.
Another question we had when Robin was out of the room whether it be organization were intermediary, we have not it assumptions that it would be intermediary based. We have assumed that a NIHN note could be an application sitting on a computer as long as it promised those.
[speaker/audio faint and unclear]
Again, we think you all for coming today and helping us sort through all of this material. Given that we are a few minutes behind, I would really appreciate it if you could confine your verbal comments to just a few key points so we would continue with all of you. So if you could please introduce yourself and jump right in.
I am Nick, the vice-president of government programs at Verisign, and I figure for the opportunity to speak today. My own background, I have some 41 years of experience in international -- and in all of those systems, I have had extensive experience and design and development of deploying system so I have some sort of practical inside as to what it takes to deploy our scale of on that occasion. But make a few comments and then I can clarify some key points about your questions and I have some specific recommendations for this committee.
In terms of Verisign, we are provider of trust services for the Internet. We provide the authority and directory of some 93 million-.com and-.net Group names and also domain servers but allows the look of domain names and Association of the IP addresses. We process some 50 billion of these lookup is called Dien asked queries every day. More importantly we also provide [indiscernible] and Evil Trust for users of devices and but sources on the Internet.
One problem we are trying to solve is enabling trust by providing -- the identity of the entities participating in transactions on the Internet. Our primary offerings that enable trust and Internet transactions are, additional certificates issued from a Verisign-public Key infrastructure for both individuals and web servers, and onetime password devices to enable strong, also known as two factor authentication primarily for remote access to Web sites. Our users can be grouped into three categories, organizations with a web site on the Internet, individuals, and pleas of a corporation or government agency, and consumers.
In terms of our customer base, our SSL digital certificates provided that the protection for over 1 million web servers. This includes most of the Fortune 500 companies, also of the retailers and 3,000 health care companies. Related to health care use of digital certificates, we recently partnered with CHQH to pilot the [indiscernible] certificates to -- the Verisign secure site field which is displayed as a sign of trust on Verisign predicted website is viewed over 18 million tons per day. We operate over 1,000 managed PKIs and region size from 400 users to more than 600,000 users. We have issued more than 6,000 [indiscernible] protection credentials to consumers for onetime password based strong authentication on network leading Web sites.
On the question of who pays for the solutions, there are two answers. For Digital certificates managed from a PKI on behalf [indiscernible] customer pays all the costs, and additionally provides the personnel to perform the activity proofing of the but employees or other affiliates of the institution. And brother affiliated individuals, IT Verisign [indiscernible] these sites are amortized across the entire base and user that is reflected in a [indiscernible]. Of tepee solutions, consumers combined are more than a dozen other vendors, or if they have a blackberry, by phone or other smart phone, Verisign provides a free download of [indiscernible] for OTP are provided for by other parties. But the primary issues for the cost and widespread paternity is, who will provide the identity proofing and users, which is particularly touching if you have a large number of widely dispersed users. This is a request by the delegation of identity preferring to trusted agents or the use of alternative methods such as Online based [indiscernible] delegated attended the proofing model.
By sense is that some combination of identity proofing and knowledge based authentication pricking is required for the net. On the question of directory services are wasn't sure about the days of your questions so we understand that the need for [indiscernible] large-scale [indiscernible] services.
Finally my opinion and the term issue that your committee should consider is what is the minimum entrance level of identity for the individuals who have access to personal health on the NIHN.
You probably decide that there are different insurance levels for different levels of users. [speaker/audio faint and unclear] may be acceptable. They decide to characterize your insurance levels in the context of 800-63 defined insurance levels but as an indicated you may find that too restrictive or it may be difficult on a very large scale to deploy. If you do precisely what 800-63 requires.
Of wood also encourage you to look at OMB policy and 06-16, it refers to protecting access to personal in identifiable information. It provides guidance that states that access PII should be done with to factor authentication, and one of the factors is a device which is separate from the computer being used to gain access. My concern is that at NIHN, it also requires a user name and password to access personal health information and that will ultimately result in significant exposure of that data. Once you have to establish the policy relate to these core issues of authentication, I believe you will find many vendors who can provide competitive authentication solutions for the NIHN. And other [indiscernible] of different credential types and who can provide assessment should be addressed.
Think you very much.
By name is David Miller and I work for Covisint. Covisint basically provides an Interoperability platform. The way we look at it, it is kind of enabling information ecosystems, and that is what health care is coming to is the idea of an ecosystem. I am very interested in the fact that you guys have decided to tackle this topic of authorization because for security people, authorization of users is almost a religion. Some people love certificates, some people loved one type password, it becomes very difficult. You have my testimony and Eve can read through some of it, but the things I thought were important, the first thing is to really understand that there are two aspects to authorization. And the thing that is issued to me, the certificate that I use of the onetime password that I use, although it does is it authenticates that I am the person who got the credentials. It doesn't say aye and Dave Miller, it just says I am the person who got the credentials. And there are lots of vendors that provide technology services that do that in no way that is probably fairly [indiscernible].
The second aspect which you brought up which is the administration is the, how do I know that Dave Miller is Dave Miller? , like IT and the credential that says he is Dave Miller appropriately? That is an extremely difficult process, that is where the hard part is. You could decide that you are going to use a PKI solution and I could tell you, those are DOD level, you're not going to pack that, but how do you get that to the person? That is it difficult model. N Covisint, what we have seen is the idea of making identities interoperable, is to push it off as far as close to the organization that owns the end user. Now that doesn't work of the time, we certainly do have decisions that sit in small offices where they don't have an organization that owns them. But for a lot of physicians, they have hospital systems or other things and I have the ability to manage the issuance of a credential. And that is the first thing, the ability to do that and people to reduce that credential. But the thing that I think is most important about this authorization is the fact that, the endpoints in these cases are people, but not systems. And people believe that they are the most secure thing in the world and it is the rest of the people who are insecure, but they are very secure. So I shouldn't have to be required to do something like a certificate or a card, I am happy for everyone else to have one because they are all insecure, but I am perfectly secure enough to have a password. So when you have that, the issue becomes that, if you can come up with this wonderful policy that says you are on to do level three, and Level three requesting issuance of something physical, and you can even enforce that, and users will find ways to get around that security if they now believe that they need to follow that level.
In a previous life where I was issuing those wonderful little tokens were the numbers change of the time to a group of executives, one of them had his kid setup a but camp and put the token in front of it, and he would go on to and unsecured side and he thought it was the best thing ever in the entire world. So those sorts of things you have to be able to keep in mind, that is the issue that says, I can come up with a policy, and if the policy is something that in the and a physician will not use, and will find the most unbelievably insecure way around it. That executive would have been better off having a password and what he did. But he did was much less secure than a password, even though the technology was unbelievably secure technology. So that is an unbelievably important thing to be able to determine.
The last thing is the fact that, one of the ways to be able to deal with the problem is to reduce the number of authentication so that they have to do. In these discussions about of indications, I am used to working in an enterprise to figure out what is the one credential that everyone will use? For example, HSP0404 is support a government enterprise. And hopefully that is used everywhere.
This isn't the way this is working here. They are talking about physicians accessing data that set at multiple external places. So let's say that you come up with a great solution for authentication, but as a physician for me to get information out of a patient, I have to enter that 20 times. I mean like it wants, but I am not using it 20 times. A real-world example of this today is the current rules that the DEA has 40 ePrescribing of controlled substances. They want some sort of physical token and they expect the physician to re-enter the code for each prescription. So if I will prescribed use three controlled substances, I will enter it three times and that is enough for physicians to go the right way, [indiscernible] character. So in that area if there was a way to be able to allow the physician to authenticate locally, and use that authentication in every place they go, they can make that authentication better local authentication.
My name is Brett Williams and I and the CT 0A mask Anakam. We sell software and we are actually functioning like [indiscernible] actually install Are software in the enterprise and some of these organizations at the table is the software to do that. And we do to factor of petitions for [indiscernible] and we integrate that fully with level three, level two and level one [indiscernible] remotely as well as professional credentials [indiscernible] the Can based platform of [indiscernible] and are you actually airports to provide position and then issue to factor authentication credentials for those. We have 11 federal agencies as clients right now at half of our business is in the commercial health care marketplace and what I wanted to do with share a lot of the experience base specifically from interacting with the HIE and R EEO that have deployed our project and [indiscernible] side of the attraction. So first of all, is the separation between [indiscernible] I can't emphasize to you what the doctor said to you earlier today, meeting to be able to separate identity pricking authentication and then the other downstream processes and understanding that each of those has a difference set of standards associated with it. One of the ones we have found in this process, itself subscribed EHR that the patient is putting the information in, there will still want to protect with a level three authentication but of 03 identity proofing is not necessarily required. I am putting my own information in there and I just need to secure it, I don't need that I am who I am two myself. So when is a differentiation of level three -- but in the proofing is critical. At the same time, David back there will probably say [indiscernible] but what is important about 800-63 is understanding that the total level of the credential that is issued is a function of each of the pieces. Level three attended the proving to us level's three attended the crates and level three credential, but understand their business processes -- don't necessarily need level three controls on either of them is important.
Secondly is the concept of federation. Federation has been lost in this and I will give him a frankly unvarnished view of this. The reason it exists is through the basic concept that running an organization, and I want to bring in people from another organization address them because a tussle with this organization happen. So organization A has Brent Williams enrolled and Organization be does not. The man had his medical records but he is not it will to access to the system. He doesn't have a name in the directory. So organization A conducts the authentication, you click on the resources, you go to organization B and they say, what is the assertion of who this is coming in? If you say it is Brent Williams, a trusted. As soon as he appears in that directory and? Give him privileges and the B directory and to enroll him, the federation is lost. So understand the purpose behind federation is accepting an unknown individual into the organization because someone else trust them. As soon as you start telling people they have to enroll in were system because it would give you a special access and privileges, it is a logger a federation, it becomes a fancy way of doing single sign on. Let's get that on the table because you may be able to find more cost-effective ways of doing the accommodation.
In other part of this conversation was brought up earlier and I can't overemphasize it. The number of places I have walked into that had purposely set, this is level to information because I can't afford to deploy a level three solution, that is why we invented our software. Level three can be perfectly cost-effective to deploy and cost-effective measure for millions of users. We have sold the software to the government, we have the largest level three citizen facing solution in the federal government right now. Hundreds of thousands of users. So the point is, it is doable and tell the people on down the information or even call it a little too when it is not actually level two. The other point is that the standards to exist. When this number out there is that people throw around HIPPA, privacy Act and FISMA as requirements. None of them actually set thresholds, they all say risk-based. So when you are actually talking about thresholds and that is what you want to get to today is the fact that the thresholds to exist on the cite the thresholds, he will be setting an 07174M0404 or this level three, if there is a special vocation, so make sure that the citations that call out what bubbles you're going too referenced documents are specifying what they are. For example, I have been working with actively with the states of California, Texas and Florida and they say there is not a HIPPA requirement and a half to put in the 03. Well do what to do business with the federal government because this document doesn't, so you have to leave on how to get there.
Lastly there are numerous proposals that are in front of the office of the national coordinator for what we call the national health-care electronic capability. Notice I didn't say credential. The NIH icy. Ended is putting in context how HIEs Rios, equipment sellers, everybody that plays a role in Healthcare Enterprise understands where an identity presents itself on the Enterprise, whether that practitioner is coming in through a hospital organization were presenting themselves through their own practice or locking in from home and coming in through a portal, how they authenticate the Internet at how their identity is trusted. Critical to this is understanding the patient and the fact that when a patient walks into Dr. Smith's health care record system and says, I want to see all of my records and being able to find that patient in a larger system that NIHN is challenging, so being able to [indiscernible] more than willing to provided otherwise. The example used cases from what we see is not based upon the application, I have heard that word, a couple times, we have to set the level based on altercations but it is better to say based on business use case. The business use case that we have isolated are patient access to their own medical records, patient access to the family members medical records, practitioner access to multiple patient records, administrator access to multiple patient records and administrator access to system [indiscernible] and activities. Understanding each of those has bubble three requirements for authentication and identity proofing.
The last thing I say is that this will probably be heresy in this room, but of the things we have learned when we get down to a surge in technology is people call PKI authentication and it isn't, it is a way for machines to authenticate to each other. Facilitate said it is important, it is all about the carbon based life form sitting at the other end of the computer, not about that computer authenticating to the other user. Some certificates and PKI to a great job of communicating who is at the computer but in the end, the authentication process that releases the certificate, the authentication process is whether they are machine based, token based or cloud based, that lets that PKI fly just like if it were a SAML assertion. So in the context we have seen it, it is better to think of PKI [indiscernible] Mike SAML is when you are tried to grab the standards.
I am Molly and I and CEO of State BioPharma as the season and I Nikki for a line as to testify today. Save BioPharma organization is different I think that my colleagues here on the panel. We are a nonprofit collaboration that was established by the world's leading biopharmaceutical companies to establish a digital entity and signature standard for the industry. A standard that would allow the industry to transform business processes to fully electronic.
Today the standard is, we were created in mid 2005. Today this standard is recognized by the FDA, the European Madison agency, we meet HIPPA and EUS Data privacy requirements. Our systems are standard in trouble with the U.S. government and [indiscernible] management system. It is vendor and technology is neutral and comprises a system of government policies to which every member and participant is bound by contract.
With that I will briefly summarize our responses to each question.
Regarding trust, this a standard was developed to provide relief the sector with high trust, who you are dealing with on the Internet is who he or she says she is, and if that identity is uniquely linked to a digital signature.
Secondly, our credentials are currently held by biopharmaceutical company employees, contract research organizations, clinical investigators and their staff, health care suppliers, mighty providers, contractors, regulators and others.
Because there are in a breast cross certify issuers we do not maintain a directory of the total universe of holders. But because of the very substantially "growing states BioPharma community, certainly [indiscernible] pass and government users holders and a growing network of several communities, there are millions and millions of potential holders that are interoperable credentialed.
Who pays for the solution? First, I think this a standard accommodates multiple levels of assurance and token form factors. We provide for our identity proving through an on-line antecedent process process which takes about 15 minutes from start to completion and can check medical license information. It can be done by notary and they will go to the home or office of the doctor or position or other user to do this face to face, or by trained and trusted agent.
The costs vary depending upon the size of the petition, the type of a attended the proofing, the form factor, etc. That said, the costs are coming down substantially, they have come down over the last number of years and they continue as these deployments increase.
We believe that all of these are in place for widespread deployment. There are interoperable standards available, technologies, processed cheese, providers, and there is a growing network of users. What we believe is needed is certainty and guidance, regarding what is an interoperable digital identity and standards and how they are applied to the end user.
Directory services. Frist, the safe BioPharma standard in credential and is fully aligned with the standard PKI authority and also with the federal Bridge, all of the cross certified issuers are also cross certified with the federal bridge. We believe, similar to our colleagues here, that authentication and authorization are separate and distinct basis of process of getting access to information. All pulls sources can provide credentials, however the owner of the information or manager of the information should manage the authorization state.
We support the role of merging attended the service providers and Federated identities and we are working with the U.S. and European governments as well as leading Standard organizations to make an alignment.
Recording a dedicated authentication model, with support authentication in three ways, pressed to cross certify issuers. Secondly, a number of our member companies have built enterprise wide infrastructures and cross certify them with safe, and a third, the save BioPharma Association maintains that the authority for members and their external partners.
What should the I think probably the very important question yesterday is, what should be the will of government? We believe that it is our [indiscernible] -- management standards and processes. These are managed under the purview of the Federal federal CIO Council and certainly incorporate I camera and the federal [indiscernible] which you heard about in an earlier panel. The stress system is used by millions of government workers and contractors and support by an expanding number of commercial providers, and is a common platform for a growing number of separate communities, including the IT safe BioPharma community, and potentially a number of others.
This trust system meets the NIHNs privacy and security and confidentiality requirements and most importantly is scalable. We recommend that the U.S. government extended these interoperable standards across [indiscernible] and two that NIHN, and we believe that effective this will be to spur the growth and evolution of the NIHN and the use of sensitive health care information and certainly will support the goals of meaningful use.
Thank you all very much. That is great testimony. Let us see who may have questions.
Take you too everyone.
Building on something that Dave Miller and Brent Williams were talking about and you sort of think about, he had to have individual users care enough about what we are talking about and get the convenience level down to a point where they are willing to actually use whatever systems we have in place, and the need for something physical. Could you elaborate a little bit on cell phones perhaps being that something physical going forward? I think next talked about that at Verisign, but I would like to know what the state of that technology is because having individual physicians, whether it be at Spearfish or full mast, use robust tokens or some sort of odd things, I feel like it will present a huge [indiscernible] issue.
[indiscernible] is based on tokens and what I would say based on -- what it's a is, he brought practitioners into this space, and what we have learned very rapidly in this marketplace is, we would absolutely love for practitioners to adopt some funds to be fantastic inside of the IT enterprise, there has to be it funded solution, there is not a one-size-fits-all solution for everybody. And so the doctor or nurse his ability to walk up to a workstation and have some cross pass at the workstation recognize who they are in the facility, or if the tickle ID card, [indiscernible] 12 critical in the government are absolutely critical. So it is understanding the role of itself on in a transaction, that the cells of could be used and we would love it if everybody bought them, but we have to fit into more of an eagle sphere of authentication solutions, and the cell phone is really better for people who are going to be going to in lot of different enterprises and not willing to carry around it 15 different cards or tokens around their neck and are one to be remotely authenticating into the systems. It is a function of convenience. That there are lots of different ways to use the cell phone to authenticate. You can't [indiscernible] people carry around their necks, and there are ways to actually -- our technology is to send an s m s to the so funds to do not have to put software on the phone. And you can deliver it to be via voice. So [indiscernible] be able to as many people. There are lots of forms of telephone me, because of funds did not work in space the underground. Pictures that work in hospitals, be able to leverage them in your infrastructure and find them as critical of that. And that fits in the total this year, that is critical.
The only thing that's I would add to that, Brandt brought up the fact that, it is not [indiscernible] but the way the real world works is, after I authenticate myself into a building for example, I have some [indiscernible] the fact that [indiscernible] the doctor that is in the opposite the fact that he has a badge and is there and is in front of bunch of people who recognize him, as opposed to the person who has access and the doctor that it's called in the battle that has access on the Internet, so a single solution just want work. Weeder Creek is a good solution is not secure enough for promote Tide access or you will create is a good solution that is a total pain. [indiscernible] critical for widespread deployment to consumers, and there are 97 people that have so funds today. The idea that they could have to pay for a token, [indiscernible] double its offer to that device, or be able to read off the code from the device, and this message [indiscernible].
And we are sort of one size fits all standard. And we need lots of different options.
After the last panel, and thought we were done. And now you guys introduced the identity proofing bursts the identity wrinkles, and I just want to ask, the government maintains organizations, many of them are included in that, and who can provide a certain level of insurance in terms of authentication.
Does anyone provide also level three identity proofing? That is commercially available that that doctor and Spearfish can access?
In the current list, they do level three face to face. Level three remote is not available on the current list. However bubbles three remote commercially listed.
So there are current providers with credentials who do face to face of in the proofing. But you are saying well there are commercially available remote [indiscernible] government is meeting.
To be honest, I have to defer a little bit with the government panel that was up here earlier, because the mechanism for getting mechanize, the mechanism is not as well defined, and our software company can get certified as level three.
[indiscernible] safe BioPharma does or something along those lines, they are certified per pack for providing credentials at a certain level and they have that mechanism and if that process is audited and supervised and monitored, that is done through audit process, whereas a number of the market benders and the process today bruises and in the proofing that would meet the identity proofing requirements,.
And [speaker/audio faint and unclear].
In terms of providing a physician in spearhead Montana a credential and to do the identity proving, that process exists today and is incorporated into government rules [indiscernible] completed and attended the proofing process that relies [indiscernible] -- It does rely on that.
It has a knowledge base process in which the attendee is confirmed and the doctor or person that science the end user agreement download the certificate as required, and it is enabled. And the credential does a person takes about 15 or 20 minutes. It is available today.
The antecedent face-to-face [indiscernible].
There are many process these that people go through to have a face to face. And for example, the face to face is required for the bank account, and that we lock them allows you to rely on one of these earlier face to face is that you can access through various databases.
You ask the questions, for your standards compliant [indiscernible] numerous standards that are complaint for this odd back. And [indiscernible] capable of meeting the federal standard yet Could Drive the cost and deductibility down, you say it is only the list that the GSA is acceptable.
If I could direct a little bit of that question of fact to NIST because I think -- there are practical and viable but not all of the same.
And the number of data base and the questions that could be answered, but you don't have the list of identity prefers based on.
If you look at level three, and I will just go back to the issues that have come up with the whole DEA ePrescribing [indiscernible] the idea was, the face to face, and the physician said, I don't want to have to go, I am an independent physician because I don't want to be associated with a hospital and a hard thing about face to face, the government [indiscernible] that has nothing to do with security, and that has to do with driver's license all the time and that requires face-to-face. That is the government willing to say, I will require you as a physician to go to it plays that I will dictate that will that and you are, and that is where the government wants to be right now.
The only part of a practical way to do face-to-face is that at that, in delegated to some trusted agent inside an organization, and is proved inside the organization, or you ask those people to go to a notary. Both of those approaches are acceptable to the federal government, or whatever kind of credential you are one to issue.
I want to move on because we have a short time and a couple other questions to that.
Based on your experience, and I know that some of you were H. As PD 12 credential vendors, obviously with all of the agency's subject to that, there credential system were wrecked and replaced, based on the new requirements.
Still looking at that situation and the health-care market, are we looking at a very very high percentage of health care organizations that in order to make this kind of standard, they will have to Rick and replace?
Our experience with identity federation which was actually there the mixture from the standards stand point was, 98% of the standards set, I don't have any tools to be able to accepted.
So the first issue was how you choose a credential and now it is what some [indiscernible] what percentage of federal government.
The authentication is very low, because there is a lot of red and replaced.
We talked about scaling this up from the tens of thousands of to the millions, because of service providers and staff, and I am very conscious of the trade-off between usability and security, and usability and costs.
And I want to bring this up with two orders of magnitude, because how does our providers now the provider is sending intermission, the patient's designated PHR, although I can barely read my mind around the level three of the petition, I am having a hard time wrapping my mind around the identity proving portions [indiscernible] to discuss that.
So if we are talking about 100 million or 200 million users, that we are not going to be face-to-face. We don't have enough trusted agents, and it helped system practical way to do that. So the reality is to [indiscernible] if you go to the pull the standard, it requires proof of that process having been done [indiscernible] the user address, but there must be some way to work your way into that, but some practical form of knowledge based authentication is probably the only way that you will be able to identity proof 200 people.
One thing I think is the difference here is that in order for that to be generated on me I have to have seen a physician. And you have to do face to face [indiscernible] when I walk into his office, he knows who I am, so leverage that capability. Allow that this is into issues that give ability to the physician and manage that and interestingly enough people to see what may be what I am looking at.
And in the same way, 2I get my prescription filled, Tull if I get by pill, it has to be face-to-face and know that there is simply the on line type of thing. So that is a place to leverage.
[indiscernible] Rios, because in all reality that is a place where I could have the equipment and infrastructure because in [indiscernible] running in that particular facility, and at the same time, the Rios and the HIEs that are seeing the information between the organization had that system and provide the capability for people to beat either remotely identity proved or have people that are delegates that are face-to-face in that infrastructure.
Let's move on.
I have one quick question. And it has to do with the issue of, some organizations proves the identity, some organizations relies on that prove in order to authenticate the user, and then some organization conveys that authenticated status and identity of the user and another organization. And we didn't mention the certificates here and it is not clear to me, where does this certificate, where does it issue and where does it get placed, and if a notary comes out and visits me, what happens electronically then going forward, and are the standards in place and [indiscernible] to that series of steps.
They talk about this and basically what it says, separate from issuing, then you have a mechanism to is how [indiscernible] there are a number of ways to do that, attended the proofing individuals, so that they could then get a trick credential that could be used to access the government mended. And at the conclusion was that it probably needed a conclusion of infrastructure that actually passed that binding from the authenticity prefer --
Bye credential, do you mean something physical that they could hold a?
Well whatever form it takes, it could be a piece of software that is a Digital certificate or a digital certificate of a hardware token, but whatever [indiscernible] [indiscernible] -- we could do that in the PKI world but basically it involves, the user has to come to the system first and the difference, and he takes that to the notary for example and when he comes back, we are able to bring him back up or bind that information we gave him the first time so we know that the person that got the identity proofing is a person that comes back against the authentication. [overlapping speakers] so postulate that we know how to get -- how to prove an identity, and bind it too something, blinded to what? Blinded to a digital certificate, and how this gets conveyed through the ID system is what I don't understand.
A digital certificate is in credential in the sense that it treats your identity. So your identity gets admitted into the certificate. But it is this some place.
It is absolutely bits, but there is a format -- I'm understand that.
So you have to protect on your workstation and if he wanted to be portable you have to put it on the token to be able to take it.
So one way to do this, you could do it the way they did it in Canada, because candid and said that [indiscernible] certificate will be in and you are one to go to a government office, they will look at your face and your driver's license and look at other things and they will hand you a physical thing that is yours. And the other thing that the Canadian government said is, if you miss use this, will put in jail. But if you don't want to do that, you would have it so that, if you go to the attendee store, and there are 20 possible things. I could register my phone with Anakam or get a smart card or whatever thing I want, and they have that ability, but in the end, I have to walk away with a thing, because it the security weakest link is, if you separate the issuance of the credentials from the user, that is where --
And at that thing has to be able to convey the bits that are that Digital certificate to some other ping, is that right?
[indiscernible] Rye SA, said it PKI is the authentication, and what we're talking about here is, we get a string of numbers, because that is what PKI is. So the key is, if there is an authentication rules that that establishes how that string of numbers that goes flying away from that whenever you stored and go to someone else's system and say it is you, that is a level 39 that allows you to go flying or in the platooning and where is that record to sit before it is allowed to go flying? And how is it protected?
And this is actually an assertion of an issuance during. And I am told, I can release it, it can sit in the repository of buy access, laptop, or if you have a USB thumb drive, that process is the credential issuing process.
The interesting thing is that a technology like SAML with PKI does the same thing. The authentication does the SAML assertion that just completed the authentication.
And there are several things you can do. There is one thing over another in implementation, but understanding that the thing you get is in number and if you have to have a will set a run what releases it and uses it.
Our last question will be --
Same question, what is the absolute minimum that we need to deal to enable secure authenticated Health Information Exchange? Identity proved and authenticated.
My recommendation is that we separate out authentication identity proofing and establish the requirements around those using existing standards that are established by the U.S. federal government, and look at the individual processes within the health-care industry. Patient access to data, provider access to data, family access and you say, what of the requirements for all of these business processes.
Sell what do we need to do?
The minimum is, you do nothing at all, and there will be some bad compromises but in the and it will work. It always does.
If you want to kickstart this, and no one will like this, but if you want to kickstart this come at you do it the same way you do with prescription pads. The Department of Justice says if you misuse the credentials, we are putting you in jail. If every physician at a credential that they protected the way they protected their physician Pat, there would be a problem. The problem would be what technology are we going to lose but the problem would be how we identify the physician. I know that we don't like doing that in this country but we do a physician pass. Make that the EAP the issuance of identity for a physician.
We're there other minimum suggestions?
Maybe based on their experience in a lifeline sector and maybe I am missing something here but we believe that the process these are [indiscernible] today. And it is down 38 Freddy of processing is. One is the on line in deceit and process, when is if I work with the International Ashbery Association, it sends one face to face, and enterprise wide vetting for a medical institution, if you can do it that way or through trusted agents. Everything is in place today, the providers are here, the process these are here, they are codified and the U.S. government has it. And we maintain that what is lacking today is a framework and clear signals to the broader NIHN community that was required around identity management. But again, they are all here and certainly when they do an analysis of existing cost versus the potential rewards of moving to on-line business, it is all in place and ready to go.
NICU all very much, it has been very helpful to us and I am sure that will have a chance to talk to you all again. [APPLAUSE]
We have one more panel. Thank you all for your patience, and I think we're gradually refining this. Before more presenters, one of home I think, Sean will be by phone if I understand correctly.
That is correct.
Okay. We have Sean a listed as the third of therefore presenters if that is all right.
No problem at all.
That you gentlemen for joining us this morning. And I think you have now seen as the drill, we will just jump in. Frank, you are listed first.
I will torture you the least and not making pronouncements last name.
Thank you very much. I represent [indiscernible] workgroup four and the assurance. I am also [indiscernible] for health care [speaker/audio faint and unclear] I am very grateful and thank you for the opportunity. I submitted what I believe is the shortest written testimony and hopefully you'll appreciate that, and I will try to to verbally the same service. I will try to keep this very focused.
You will find that their testimony is a little different. We're not answering specific questions, because our value is a little different.
Kantara is a consortium of 000 linear organizations, many within the U.S. and [speaker/audio faint and unclear] and Asia and Egypt, collaborating to the fine standards that help us advance privacy, identity management, Interoperability frameworks that would allow more on-line transactions to occur.
By definition, our focus is not industry specific. In my work group, had the pleasure of working with David and Peter and rich from safe BioPharma and a few more that are sitting here before you, so we have a broad representation for multiple cross sections of the industries. We have taken on a very interesting task, we have become almost a purpose now, which is to try to address and come up with a free-market in which you can establish levels [indiscernible] something bigger problems that we are talking about today, you enable record health care changes, but [indiscernible] also faced with similar views cases that deal with financial transactions or protecting sensitive data such as the DOD scenario and so forth.
We have come to a conclusion that as a cross-section of the industry, everyone seems to convert and [indiscernible] demonstrate different levels. And not to your surprise, we have started our work based on [indiscernible] 0404 in this 800-63 special publication. The have collaborated with those entities especially with NIST and latest round of revisions to that standard or that guideline.
What we have done is taken those documents as a baseline and decided that, to make this an operating program, something that could be actively coordinated or stand out as a program, there were other programs [speaker/audio faint and unclear] so we put it out as what is now called an identity free market that was permanently lodged last year.
On one hand, we actually take the NIST and zero and the definitions of identity assurance and we call it in what I would say is a little more detail in describing what they actually are or what they actually mean. And in doing so we have taken perspectives that are not only [indiscernible] specific. We have taken into account the European points of view and Industry points of view, for example still communications and so forth. You'll find that our definitions are compatible and in line with OND0404 and NIST, but we believe they are a little more prescriptive. On top of that, the NIST aspect of their free markets, is there a way that you could practically stand up and say, I and a provider at this particular level, and for that to convey something to remind parties so that's that transaction can be [indiscernible]. And we are able to do that 22 elements of our free market. When his assessment criteria and that is three pieces. Building from what was discussed earlier in the penalty for this, there are three aspects of that series of the assessment criteria. One is the strength of the credential itself. How does the strength of that credential map to an insurance level? We have gone to the issue of not necessarily prescribing that technology but what characteristics of that technology do we need and qualify for secretariat? We also have a component for identity proving. So we have criteria for two -- the identity of the vetting process has occurred. The third element, and I think I will address your earlier question, the ongoing operation, the operation and oversight that the organization [indiscernible] to conduct their business, and so that is part of the services rendered.
So for you to get credentialed for a certified, you have to satisfy all of those three areas at that level. So that is one very in Port component of our work. But the component that I think makes it pragmatic is the next one which is the assurance assessment team in the certification program. Now we have an operating program. The program addresses to actress, one is the identity provider for the credential service provider, and the other is the assessor or auditor community. So the intention of the program is due Credit the assessors so that they are confident and qualified to assess based on the criteria that is defined, and when they complete an assessment of the credential provider, for that provider to Edmonton evidence to this program, they satisfy the criteria. At that point, the credential predicates granted the right to claim that they get by with our specific level of assurance for our program. So that exist today. This is an operating program. Plunge did last year, and -- we launched it last year, and [speaker/audio faint and unclear] in the number of industry areas.
Let me conclude with a couple of things that are not like to highlight, a beach just to build from what I said earlier.
We have a program that I believe addresses a number of the questions we have seen discussed here today. To "Peter, if you don't need to invent anything. If we could just let breached the program, it is available for use now. It is not a specific health care program, so we think this is important for the adoption sake that we have a [indiscernible] free approach that not only addresses use cases in health care but is a broad cross-section of the industry. It is technology agnostic. You are not blocking your community into a specific approach and whether it is PKI or SAML does not matter matter, we are looking for any particular technology. It is compatible with your over and specifics and standards that have been discussed, in the NIST and 0ND. Maury importantly, it is now under review by the ICAM [indiscernible] management program and the CIO, and if we complete the application, it will be the first trust remarks service provider that will have completed the program. So that should give you insurance or at least some comfort that we're very closely aligned with the federal requirements.
The last point I would like to make have hasn't really been tested in a number of related scenarios, and I listed some in our statement. The federal health information exchange has taken our free market and put into practice in some [indiscernible] states. For example, Connecticut, Michigan, Minnesota, Nevada, Ohio and Texas. By adhering to this common standard, you could broker trust in these systems. I think the work being done in the Michigan Health Information Exchange in particular is further along in implementing, incarnating and adopting this program, so you could really scaled the reach and the ability to have credential providers in your network.
Thank you very much. Matthew? Thank you for being here.
Good morning. Thank you for the opportunity. I think it will begin my remarks today by taking exception to one thing that Frank Just says. He in fact has the second shortest testimony today.
We do have one other level. It is not really authentication, but it is an extra step. We advocate the ability to put certain clinical information behind the Great/functionality so the physician would have to then declare that that information would be needed. An area of example would be HIV diagnoses web test and medications. We certainly view these types of deliberations as a final role of government. We really appreciate the setting of standards for organizations such as ours. We are all adhering to a perfect level authentication. Certainly, for us to continue to engage in the nationwide Health Information Network exchange having this kind of conversation and the assurance that others are holding true to the level of authentication. Thank you.
Thanks very much. Shawn, if you are still with us, you are up.
All right. Fantastic. I hope you can hear me all right.
I want to say thank you for the opportunity to participate. I am sorry I am not in person. I had some circumstances of a holiday that held me from being there. The group we established about five years ago to improve health and wellness. Course identity and authentication are critical pieces in everything we do. The first and a lot to cover is to talk about what I cannot cover today, which is there are many different types of identities and relationships involved. Providers, clinical users, organizations, users, and subjects. We have talked about a number of them. I think they all deserve their own discussions, but for me to cover them would not be possible. Instead, I will focus on two specific use cases I think have the highest potential to engender providers and accelerate how we get to meaningful exchange. In particular, I do not want to talk much about authentic and users in clinical systems behind the end points. I actually believe that attempting to institute a nationwide Federation of end user is not necessary or desirable at this time it is time to say that there are important [ indiscernible ]. It seems clear to me that broad adoption of claims based, access control to consolidate will improve. It is simply an issue I don't think needs to be solved in the context itself. I think our first thing is organization to organization authentication. There really is no large distributing organization in the world where it is truly global.
Especially with health care, this is a good technology issue. It is usually about regulatory barents, and business competition issues between providers that contributes to make multilateral trusts very often or practically impossible. I think we really need to use organization to organization authentication and authorization for sharing records using some kind of .2. Trust. [ indiscernible ] any organization approved by a body, for sample. As it turns out, the Internet community has a technical model to support this full range. The hierarchy that drives it on the left by using the same [ indiscernible ] to authenticate both sides of the conversation together with purely local configuration and points [ indiscernible ] I think we can immediately jump start a whole bunch of private data exchange. There are a few key points relevant to the things that have already been discussed today. Number one, this model relies on the organization's certificate or certificates for policy decisions. Rather than coding that into the protocol's themselves -- for example, we talked about sending details of authentication methods in the envelope of request. I think doing that is very, very hard to prove. It is easy to get overly complex. It is natural to pull something like that level decision out of the protocol and rely on the proxy. I no [ inaudible ]. The other thing about using open a 30 model is that it has different levels of business models behind verification. We talked a lot about the costs of different levels of that today. Again, if we allow different providers to provide different levels of service, you do another good job of proving the system of best practices involved. The first recommendation for government action is we simply specify the use of hierarchal digital X509 search.
While we believe any authority should be able to grant certificates, the federal body should kick start that process by standing up to authority to grant certificates either directly to organizations or perhaps to the states who can then issue next level certificates to organizations within their jurisdiction. The second piece everyone to touch on is about patient identity and authentication. We know what the goal is in the end. Sharing information not only between [ indiscernible ] and patients as well. To claim their own health information, it is really important that identity match is perfect. This is a little bit of a new issue. It is not acceptable for me to be granted access to health information that belongs to [ indiscernible ] as well. This is a problem because all patient identity matching in the current specifications relies on demographic matching. It is one that by definition always carries a nonzero error rate. Beyond approving issues discussed earlier, we do not have at our monthly -- not likely to have [ indiscernible ] that would use that effort across [ indiscernible ]. And today's world, the only truly reliable method for going to call records is organization by organization match based on the person encounter. I really don't think it turns out to be the case. Our regulations must make a document request to receive information and they visit their providers in person to take care. It is a relatively simple matter to piggyback these on top of existing practices. Given that, our second recommendation for government action is to resolve this gap. Augmenting the current mashing out rhythms specified with a perfect match alternative can be used by citizens to claim their [ indiscernible ].
A they already use variance to link them with artillery clinical systems. Further information is online. I think we could translate the same patterns into something that would accelerate availability. With my high speed talking, which I am willing to do, that is my testimony. I look forward to questions and conversations.
Very helpful. We will now move on to the last presentation. Thank you for being here.
Yes. Thank you to the committee for this opportunity. My name is David Macaulay. I am a longtime associate of [ indiscernible ] in Kansas City and also am member of the standards committee. I have a a fairly lengthy testimony with sales, so I will just briefly summarize. Some of our experiences in dealing with some of these issues of distributed identity management and authentication. I will do this with the thought of coming here is some real world experiences opposed to the theory and the profound technologies that we have available to us that we have heard about earlier this morning. Turner, as you know, has facilities all of from the world. I think we have one in spearfish, Montana. Although, I would have to go and verify. In all our facilities, we -- in the E M R facility, we get our clients the opportunity to add whichever second factor or strong factor authentication they would like to region from fingerprint readers to tokens or smart cards, et cetera. I queried the team that does that work for our clients. They felt they were pretty comfortable. There was less than 10% of our clients that opted for any type of second factor authentication.
I went back several times and said, are you sure? They said, it might even be less than that. It is uncommon in the real world for physicians inside the institution, anyway, to use these additional factors. The issues that raise our complexity, cost, legacy systems that cannot interface with them, but first and foremost it is the burden on the productivity of the provider. I do not think that is a surprise, although it was a surprise to me on the numbers. Turner Systems support Federated authentication to an enterprise within an enterprise using a variety of mechanisms that have been discussed this morning. We find far and away the most common approach to enterprise authentication of sharing is single sign on Viet screen scraping. Once again, the driver is that hospitals have so many legacy systems that do not speak these modern protocols and screen scraping is lowest common denominator. That is actually what gets used. In my team, a very informal survey done over the holidays, so take it for what it was worth. Probably only about 30% of our clients even leverage that technology, the low level screen scraping.
We will shift focus to the non provider but really toward community including non physician users of the system such as administrators of hospitals. We established, recently, an internal social networking service that is designed to pull all of our clients into shared conversations with associates that develop the software and the third-party suppliers to help us to deploy the software. We call is [ indiscernible ]. I don't know that I like the name, but that is the name not stock. The goal was to get as many clients hoped up and registered as possible to do it as quickly as possible. We initially tried to do that via a Federated authentication model. We would take the people who used our software and automatically grab them trust relationship. It was a dismal failure. Not for technical reasons. We were able to get the code to work easily, but what I would call identity granular he mismatch. The number of people authenticated into one system we're not the same people that needed to be authenticated into the other system. To solve that problem would have required us to create fake or dummy accounts in a system to get access in a social network. It would have confused the boundaries of what kinds of information should flow. Should patient sensitive information be allowed into the social networking service and so on? What we did as alternative was we stepped back and said, well, the email addresses assigned to the users of our client's email system is a pretty rigorous and trusted entity. It is, certainly, not as strong as some of the things we have been talking about this morning, but our clients are very careful. I am sure everyone of the organizations we work for today it is.
If everyone gave me their business card, there is an email address on there that I would have totaled trust that I would use that to communicate with you. We try to leverage that model to build this deployment. We create a white list where they can register. We send them back with a message to their email address to prove they own the account and a complete the registration. It is quick, it's simple. I believe is starting in July. We were able to -- We have over a thousand clients who had activated that relationship and over 16,000 authenticated users. So, the process works well for that particular use case. It was leveraging a kind of trust with the email address. Let me speak now a little bit about patient authentication and connection. I believe one of the earlier panels made the suggestion that the provider Could Drive the identification of the patient. I think that is an interesting idea. It is kind of how our system works today. The consumer who wants to get a message from the provider via a secure channel has the registration process at the front desk where they established a shared secret message sent to that ordinary in the address. The logged onto a secure website and prove they know the answer and establish that relationship. It works will done well. They can just add a provider to their current account. It is still somewhat cumbersome and puts some burden on the front desk, but it is a simple model that leverage is the fact that the provider it knows who the patient is.
You ask the question about directory services and integrating with outside directors services. I will describe the problems and successes we have had with sure Scripps and degrading to our prescribing system. Another special here, but the issue is identity regularity mismatch. The way the sure Scripps identifies providers and the definition of a provider does not match the way millennium identifies providers. In either is right or wrong, they are just different. The mapping process between those is nontrivial. It is currently done by hand and requires in some cases some cumbersome work around where we have to create pseudo identities in our system to match what they expect in their system. It works and two separate locations, the return request for a refill needs to be location specific, so that identity is normalized in to the directory by sure Scripps. That is not how millennium sees it. We see just the providers. Mismatch is an issue that needs to be wrestled with. Let me skip to the question of the role of government and what it should be. I will give you a use case that I would like to see us be able to solve in the near-term. And knowing full well that the long-range solution is something that we should keep in our long-range radar, but the near-term solution is, how can two providers securely share patient information in a push matter where one provider sends something critical to the other without having to resort to complicated procedures to assure that the security and privacy of that message is uploaded? The use case is one of my colleagues came to me and said, one of the patient lab results came back late in the day when he saw the numbers and he knew the patient had to go to a local emergency room. He wanted to wrap up the data in his [ indiscernible ] and send it in a file or message to the physician describing the fairly complex medical history. He wanted to know if he could do that with regular email. I, of course, said no. You cannot do that. That is not an encrypted channels. It is not secure. I suggested a process where he could sit it up, put a password, text it, et cetera. Ideally, there would have been something that everything was connected to.
In our Kansas City region, there are at least three competing organizations trying to establish that footprint. Neither of the two were a member of any of those three. By that is a will be several years at best before that issue is settled as to what is local HIE and what can activities should exist. The simple proposal, which goes under the name of simple and dropped. I will be straightforward. Wes and I have collaborated along with Sean and some others in thinking through this period could be. An organization to organization trust at a mail service level using secure authenticated T LS between the servers such that the locally assigned email identities of a critical source such as the providers could be leveraged to greet the secure channel without requiring the top-down management and issuance of all of these sort of top-down management identity we have been hearing about this morning? This proposal would certainly be a stepping stone toward a more widespread, full model with approve of your identity needs to be stronger because you are not dealing with known personal relationships. I think I will stop there and see if there are questions.
Thank you very much. We ask the panel for questions. Yes.
To David, I have been enjoying the on going updates on the interoperability string. I guess it seems at the model that you are talking about is one that could involve into the full end user authentication level three assurance if the organization that gets that certificate then assumes responsibility for identity proofing. So, the model might be that the organization might be a hospital that assumes responsibility for identity proofing for the providers, or it might be a vendor to small provider offices when they are implementing the system does identity proofing. When you look at the driver's license, make sure you are a physician before you implement the system. Could you comment on that possibility of having the delegation of identity proving even to some of the Level three assurances and credential in not being done at the organization's that are the hold interoperability model?
Yes. Thank you for that question. I think that is exactly how it ought to work. I think the model is layered on an assumption that messages are typically between people who know each other and trust each other. The primary issue is the security and integrity of the message as it flows. That, in most organizations, already exists in the form of email addresses. It could be converted into secure email addresses following the same process that they allocate email addresses. Going it from that to a poll Model where you ever get about a [ indiscernible ] and you don't know who they are going to be, when you move to that model, you have to ratchet below of trust up. The simple proposal to start with is something not controversial. Eventually, let's move to a more difficult role of authentication. I cannot see any reason why they are incompatible. I think that process has stepped up. I think we heard this morning a variety of ways to do that. I'm not have answered your question, but I think the answer is, yes, it is a natural progression as Shawn said, it leverages the organization to organization trust at the starting point and goes from there.
Anyone on the phone, any of our members want to get in a question? If not, West is up.
I suppose I should make some comment about that [ indiscernible ] you are collaborating with. I am wondering if you would agree with me that Dave and I have learned over the last couple months that he is black and white and I am in shades of gray. I am about to go into some nuances here. The push model kind of leads over into a great model and into a full model if you push a request and they push a response back. In that sense, for example, the work with Social Security Administration that falls into that model. Would you agree with that?
Yes, yes. I mean, again, is that an automated response or is that a human mediated response? Obviously, different requirements.
Right, right. At a minimum, we require that the operator of the IT at that implement these servers and so forth meet some criteria not yet established to be trusted to operate. So, we are specifically not envisioning all the practices. We are expecting they used either their vendor of their EHR or some entity we have thought to call the health information services provider. In whatever that method is for accrediting those entities, we could apply the processes we have heard for a crediting them as identity prefers as well.
Right, the notes would be required to go through a fairly rigorous process. And users would have to follow a policy driven process much as we have been discussing all morning. What exactly to that policy be and what should the fine points of the rigorous actions be? I think it would be less rigorous to start with if the use cases confines to the plush models because of the fact that that tends to be between individuals who already know each other and are engaged in central care. They are fulfilling a duty of already agreed upon cared process. It is a somewhat lower standard. I thought John's point about matching and patient identity it is absolutely critical to the 800-pound gorilla in the room. I look forward to the revised version that breaks out into more detail. I think the use of things like the cellphone makes tremendous amount of sense as a fairly non invasive way to radically increase the security of the conversation.
Immediately in my head, [ inaudible ]. Now we wrestle with the practicality that you go through these [ inaudible ] at all times. You do not need a strong credential every time. It would be regressed to go from one level to the other. When you think about how you go from one level to the next -- as you said, there is established trust. There is some baseline. How do you go from that base line to the next? I approach it that way. You simplify the end user experience and hopefully reduce costs. There is a comment from the last panel -- a comment from the last panel. I think the level of assurance tend to intimidate sometimes. I am a believer that that is not the case. I think that it would mystify that. This could be a way of doing that. You will find it to be less invasive. People are more likely to live.
I want to throw something in if I my. I know it is hard. As you think about how those institutions get their certificates and what they have to do -- a number two, is not necessarily a problem we have to solve once and for all. It is the idea of having many authority providers just like we have many consumer advocacy organizations. It could be very powerful to say that point to point or region to region communications, there may be sharing. They may be able to work out front and policies and [ indiscernible ] between each other. The point being, and open fact that allows for different levels. The institution gets to choose, do I believe that that is sufficient for a particular transaction as you go from the different ones, the push, the poll, the individualized and so fourth.
I think our brains are fully saturated. We will need to get some fuel to process all of that and come back. I think we have an opportunity now. If no one has a question, we will adjourn this panel. Thank you very much again for making the time and trouble to come help us today.
[ applause ]
With that, and we have an opportunity for public comments. Any people in the room here that wish to give comments. Is there a microphone for today? The microphone was not on. Hold on.
Okay. On the telephone if you wish to make a comment, please dial 1-877-705-6006. Or simply press star one if you are already connected. We will begin in the room with you, sir, if you please state your name, organization, and please keep your comments to three minutes.
Thank you very much.
My name is Chris. I am a senior vice president at T. FNS, transaction Network Services based in Virginia.
We are a global communications company that provides and manages telecommunications infrastructure that the payment industry relies on to secure it to transport -- [ indiscernible ] and relay information. Telecommunication carriers rely on. On a monthly basis, we transmit over a billion actions a month. We have over 2 billion devices dispersed geographically connected to our networks that are connected to our customer's networks. We want our infrastructure on a community-based network enabling cost effectiveness and [ indiscernible ] with each other. We manage interoperability it between those customers associated with multiple standards of protocol. Each industry we operate also has transactions and all sorts of participants that participate in our community of interest. Three common themes discussed. How you build trust? How do you from an authorization standpoint? And then using existing technologies today. We have been around these industries as well as financial services and have seen these evolutions of similar networks. We have recommendations that this committee should consider when we talk about authentication. First of all, run an intelligent network via an extra net with a centralized registry approach. Okay? Services such as authentication, security, and privacy can be managed in the network. It can be managed in the edge as well as in the network. You build architectures that exist not only to support Information, but there is no interoperability associate there. They can take care of the interoperability much like we do in payments. Registry approach will allow participants to affectively exchange data between each other without the cost associated building these huge centralized data farms. Essentially, it alleviates the privacy concerns about having a centralized data. You can manage remotely between participants point to point. More important today's is discussions, as you set levels of authentication outside the edge, the registry approach will allow you to manage who can talk to who based on what level authentication. Second point, bridge the technology gap. Health care industry is a complex environment of standard protocols. We know that. It could take decades. As we see the financial-services industry, the standard protocol has been adopted and allows electronic communications not only nationwide but globally. What is also important is the establishment of a single protocol does not mean there is one extra debt. There are many competing today in the financial services world. Lastly, I think the thing that the committee needs to consider and allow from a business perspective is that sustainability and scale ability is critical. Remote authorization. We talked about what could happen in the HI eWorld. The problem is the scale ability is the business is very difficult as you grow from a small regional area. You're not going to be able to scale the business. That will be a sustainable growth model. We agree that authentication can happen, but the problem is if you get enough transaction across the business that allows the business to grow. How many networks were there 30 years ago versus today? Just consider that the scale is a big issue as to think about authentication as relates to this from a legacy standpoint and from a business standpoint. Thank you.
Hello, my name is [ indiscernible ]. I am [ indiscernible ]. I see a big problem with the current situation in the proposed solution. The patient data [ indiscernible ] in many systems. At the same time, in particular -- [ indiscernible ]. [ indiscernible due to heavy accent ]
Summed up now, please.
[ indiscernible due to heavy accent ]
Thank you very much. Sir, you have the last word.
Good afternoon. I had to check to see what time it was. My name is Michael McGrath. I work in North America for a digital securities company. In listening to the discussion today, there was a lot of discussion about identity proofing. I want this work group and the policy community in general to kind of think outside the box and not work in a silo as solely looking at health care in general. There are a lot of identity initiative going on currently. One of them is revamping the Social Security card. Senator from New York introduced legislation in the fall to have a biometric Social Security card for immigration as part of the Immigration reform. That social security card will require in person identity. It will require the citizen to provide a fingerprint and will find that credential to that person. Okay? The existing infrastructure is there to service millions and millions of people and it is grossly underutilized today. It utilizes -- that was discussed briefly today. I do not want it glossed over. As we all know, the Post Office is running deep in red right now. They are trying to cross train their existing work force. There is no better way to utilize that work force and those locations to identity proof whether it is the consumers, patients, or providers. I want to stress those points. The existing infrastructure is there. The other thing is that early in my career I was a stockbroker when I first got out of college. I had to go in person and identity approve full I was to the police station. The FBI has my finger prints on file. As a stockbroker, that was a requirement to provide those fingerprints because I would be managing money. Okay? I see no reason why HHS can't mandate the same things. If.
Can mandate stockbrokers to provide standard Brands and you identity proving, the State Department requires citizens to do identity proving -- it is logical that HHS can follow the same suit. Thank you.
Thank you very much. Nobody on the phone.
All right then. We are fully prepared for our discussions this afternoon of how to move forward with recommendations based on the input we have had. I think for now we have a break until 1:30. We are exactly on time. You have until 1:34 a break. There was some discussion of there being lunch available for purpose. Not the case. Everyone is on their own for lunch. Thank you all. Thank you for the witnesses for coming and joining us today.
[ NHIN Workgroup Public Session on break until 1:30 EST. ]
My fellow panelists, but while you are all happily munching, look restart the formal session and the live on the wed, so be aware that what is a Maybe broadcast globally.
We have little makeup kits to pass out.
Joe, if you asked Chris to open up the public line?
You are already stead, Judy.
We are? How long has that been going on?
For about 10 seconds.
All right, and think we're ready to resume the NIHN workgroup meeting, and Dr. Lansky and Danny is here so please reconvene.
Is anybody on the phone? Mark?
Well, our intention with this next hour was to digest what we have heard as well as our lunch, and see if we have at least some way of framing the authentication issues in light of today's testimony that we could begin to use as a way to populate the recommendations that will come forward in the next week or so if we are able to come up with some. I will be pleasantly surprised if anyone has fully processed all of this and is ready to lay out a free market. We are in trading one up here. -- we are in trading one up here. Maybe I will start by going around starting on the phone with any comments they have based on what they heard this morning, and after that round we will try to put together a template, but Mark, since you are there, do you have any reaction to where we are all?
[speaker/audio faint and unclear] challenging and I can't remember which Speaker it was that said to bear in mind about the [indiscernible] providers or patients [speaker/audio faint and unclear] well to be different. [speaker/audio faint and unclear] that is my only substantive contribution.
Is anyone else on the phone?
Let's just go around then, and first community members and then other interested parties give their thoughts.
Mickey, do you have anything?
No. I mean I think the recently more layers to this then I think I appreciated before we started talking, and that last-ditch effort of identity briefing at the end of today and how key that is, and I will say that I think there are a variety of ways that want to think about trying to make that more efficient based on different ways of identity proofing today, which could be different whether it be licensing or what have you, but I don't think it is unreasonable to go down a path of saying that, the face to face identity proofing is required, and the physicians ought to consider that they have to do that as part of participating in the health Exchange, and that feels to me like we would do that in many other areas and we are taking on a pretty big responsibility here, and I don't know why at the end of the day it feels like with to shy away from that.
I think what I heard this morning was that, there probably wasn't a one-size-fits-all solution to this problem, and that our framework has to accommodate individuals as individuals, in a solo practice decision. And within individual organizations where there are existing trust relationships because of some sort of relationship between the individual individual or organization or rights to practice, those sort of things. And and think the other thing that we have to consider, and I am not sure that we heard it very clearly this morning, but what I am calling NIHN business associates, this is the idea that information flow may not only be from provider to provider the at the NIHN, but it may also be it the intermediaries that will facilitate the exchange of H.R. information, for example the vendors that may wish to stand up there on gateways to serve their customers, but where I think that will be especially important is where the software assertiveness realm.
Not a one-size-fits-all solution. Let's recognize that there are different trust models, and they don't always necessarily follow credential in at a particular level of assurance.
Okay. First of all, this was a very good session. And out like to leave the panel the way it happened. And whether you agree or disagree, [indiscernible] was very [indiscernible]. One of the things I heard in their work, maybe it is a good idea to go to the meaningful uses or some other delineation, or do we just declare they are all global three and move forward? Or it might even be variations within three if they are all conservative based on every patient information, but it is not all patient in formation, it is not clear because we're still sweating that detail about.
There were lots of great ideas and comments that came to mind about how one can use the context to leverage the changes in security from what might be a level to tweak a level three, and that is the question on the table.
There are a lot of good comments made to start to put pieces together of a trade off from a big centralized model versus eight decentralized versus a sharing of standards, and some of them are exclusive, so those are sort of my big comment.
Quickly, I thought the format was really good, which was a little bit better and I agree with having the -- I had the good fortune, and I don't know if a state by former [indiscernible] a few years ago about authentication and identity management, and I think I talked to four different HIEs and both markets were part of that, and what became clear was that there was a lot of variation in how they do and don't authenticate, and that they have some inherent treats and weaknesses in their abilities. And there is a need and a role for a federal government or a government body of the NIHN to set some basic requirements for how providers who are going too participate [indiscernible] are authenticated because I think it is a little bit [indiscernible]. The other thing which is a small but important observation, I know that the Microsoft folks and a couple of other people on the panel today mentioned patient authentication, and I think that is an area that we could spend a lot of time exploring. And it is interesting. I think as we think about authenticating patients, one of the areas that I want to make sure that I have in the forefront of my mind is the diversity of the patient must be like the diversity of the providers, it is definitely not a one size fits all solution because there are a lot of patients who will not have access to the system or access in ways that we think they should. We want to make sure we can facilitate things like online visits and multiple ways we can connect [indiscernible] Start office hours, and how we really should be flexible and yet secure in the way that we approach that issue.
No comment. I will make a few brief comments, I felt like it with no big surprises but I do think for our own deliberations it would be good to separate that discussion of provider and consumer authentication because they are very different problems. And I felt even in the discussion this morning things were getting planted in the discussion. But I did think the question of the authority or the organization issuing death certificate is one that we should grapple with a little bit.
We had a discussion about having a list, not a very useful list, but about whether they are adequate service fires or survivors.
I do think that is an issue and I want to go back to the question of how to leverage the national provider identifier as an identifying element in whatever this construct is, because it may get us a long way there. We need to discuss that.
On the consumer side, it is a much more concentrated issue, and I do think there has been some progress there and I would love to discuss that.
I heard a number of teams come out during the discussion. When is the need to keep the medication and identity proofing process local and as close to the provider as possible. And I think it will drive certain policy and architectural considerations that the organization is doing, and the authentication need to be, if not geographically at least from a business perspective had a close relationship with the providers.
Number two is the need to tightly couple the policies free market and the technology framework. That is, the technology doesn't give you anything independent of the policy and procedural framework that drives the process. You could have all of the policies and the world but it will drive down towards the weakest policy implementation. They're is a need I think for a standard policy framework.
The third thing that I heard and then I heard refuted was the notion that level three authentication goes from an identity proofing perspective and authentication prospective is that there is technology out there to do it, and the only examples that I heard at levels three [indiscernible] complainants relationship, because there is a contract in entity with the federal government who is required to do level three authentication. I didn't hear any good examples of level three authentication at the individual provider level and in fact, we heard from David that when the option is given, the implementation rate is extraordinarily low. I could compare it to lunch with those of us that were providing HIE services and the examples are parallel down the board that there not are not great examples because of the key takeaways and the notion that the patient and provider has.
I think the most interesting decision, and kind of issues discussed was in that last panel, when Sean and David presented the alternative model. We spent all morning talking about and user de ... credentialling. And the model there would be determining different uses, and we are talking about access to many patients, it is likely it will be assurance level three requiring to factor authentication. Then we heard that essentially there would be -- what we need to do is to buy their established a centralize process, that DEA, didn't give us an example, the government issues a provider to every five back in the country. Use your authority, piggyback on FDA, and you are done. Are you could get assurance level three, there is a marketplace out there maybe an accreditation process that is better than the current -- how you get on the GSA list.
There could be a marketplace of continually doing ways of a identity proofing and authentication providers.
That is approached A.
And it is increasingly feasible to do this, although someone made a very good point that it is one thing to get the technology or get the identity proved, it is another thing to get the technology to be able to use that token.
So I may have a 12 badge, but I can't put it in my computer right now and be able to access all of the websites I want to access and my e-mail and not having to use my password, so have and the token and the password for the technology for -- the multitude of the potential is an important thing to recognize.
Having said that, if we could figure out how to get every doctor in America token up, and it is hard to think that the future will not need something like this.
On the other hand, if we focus on our four core meaningful use stage one requirements, it is hard not to think that it will be much more feasible to get there in the near term by going to the accrediting and deeming of the organizations to get the certificate and put it on that server of the EPLF and David Macaulay and West have been talking about Interoperability.
In addition, to that being much more feasible is, it is kind of a two further, it links it into the routing mechanism of the information. So it is not just the credentials that you get, it also carries in that house the information is to be routed through the servers of the health information providers.
So, right now, I can't process it all right now, about how these two recommendations will come together, because if we go to the logical conclusion of the insurance level that will probably be three, and let the market will, it could be years and years before that capability is gone to be available to every motivated provider who wants to be a motivated user in 2011 and 2012.
On the other hand, I am not sure if the server to server implementation takes us to that other end point.
My last thought on this is, the only way I could see it taking as there is if those health information service providers also provided identity proofing. Either through themselves or partnerships with others, wary the EMR vendors also checks your driver's license when they do the implementation in the one doctor's office.
I think one important lesson that we heard that was already mentioned is, the evolution from the remote -- we are really talking about remote authentication, that is to say, we are not so much caring how a user gets access to their local EHR, we care about how they get access to the information that is communicated somewhere else.
We have also recognized that that communication is not always attributable to the over action of the users. Sometimes the systems decided it's time to send this information.
We also recognize that portals, corporate [indiscernible] blogging into a purple by someone else [indiscernible] talking about being able two remotely access an application has a user. And one of their points is that, it is not enough to have credential in system, it is not enough -- it is important to have a variety of authentication mechanisms, but it also takes [indiscernible] to be able to accept this level of authentication and it is apparently a significant investment of the people who maintain those applications to bring it up to that level.
I hope that we can however perhaps goes through the meaningful use criteria, and distinguish those cases that are remote access to an application from those cases or the communications our System to System, and the purpose of user authentication is to provide a reliable audits of that transaction, and other rates, if I am going too respond to some Hospital that sends me a request, they say it was done because Dr. Smith made this request, I have to have a reasonable level of comfort that if I ever have to go and have that challenge, I would be able to go to them and it could be anyone that said there were Dr. Smythe or not.
So I think that is important.
I think it is most important to support those cases that are needed immediately without tremendous retread of systems that have to use them.
We had a goal of achieving meaningful use, achieving meaningful use means getting Interoperability, the next few years, it has only been if used systems that have been able to qualify. If we really want, and the more people that use interoperable Systems, the more trouble they will go through to use them, and a look like to see that starting with a level that maximizes Interoperability.
This is Tim Cromwell.
Just one quick point about identity proofing in person, one thing, is there something that would be called E authentication. And what I mean by that is, are we going to have to worry about those times when a clinician move is? For a condition retires, the clinician is de privileged, and if we have to worry about that, then it makes sense to tie that in person attended the proofing concept to the credential and bodies, the state licensing facilities or the DEA, everyone goes and gets a DEA number. It makes sense that [indiscernible] had to be tied to voluntary incentive somehow.
I just want to say that it is not every physician. It isn't every clinician and there is an important decision there.
A lot of the comments I would have made had been made. But a couple of things, I am almost ready to make my comments by asking several questions. But for me, I keep coming back to this. And think this is about meaningful use of electronic health records, and so to Wes Potomac Wes 's ., or to his last point is, is that a focus on Interoperability or the small ... or is it about Interoperability for all and try to move Interoperability in their for a different one, so I think we have to think hard on whether want to push hard on certified health records versus Interoperability versus those that don't.
This is the rest of the country. 80% don't.
That changes your decisions here, so are we talking about meaningful use, electronic health records, which is how I come at this, but I also understand the pull and tug of Interoperability and getting that more engaged in Interoperability.
The other thing is, I am struggling with the initial concept of the teefourteen a system of networks versus a virtual networks that allows Interoperability for all of those local or whatever, and again, that changes some of those things.
And again, is this a provider to provider transfer of care or transfer of documents or that type of thing, or is it more or partially about in a lookup?
And some of those questions need to be developed or two ride out of those answers.
Again, to me, it comes down very much too, what is going to be the impact on the work flow to the providers that we're trying to get it to adopt. Because one, we don't want to discourage adoption and we don't want [indiscernible] with Interoperability.
There is one [indiscernible] this is not a technology problem. Very rarely is a problem a technology problem, and it so we should very seriously steer away from anything that is not a technology solution. A because it is not the right answer and B because it will currently locked in doing things rapidly. And given the fact that it is not -- another take away that came burning into my brain and I don't know if this is what everyone else heard, but it is hard to solve the underlying policy program without trusting. And the charismatic fellowship from NIH was the first panel to talk about actually enabling work requiring the people trust [indiscernible] that was basically deemed trustworthy by someone you don't know. That is not how it Burks.
At the same time, there has to be some kind of ultimate return of trust that comes from somewhere, so you have [indiscernible] someone who was basically deemed trustworthy by someone you don't know. And yet it breaks down the chain [speaker/audio faint and unclear] doesn't inherit trustworthiness, or can be relied upon. I don't know if that makes sense, but the whole notion of the actual delegation of the deeming deaf people as trustworthy, that is an important concept that I have taken away from it, and it seems to me that it would be an important part of whatever solution that we publish.
Mary Ann, did you want to join the comment?
I thought it was telling that one of the initial build were the comments that were made by the federal panel was the assumption and raising the awareness that you really shouldn't jump to the highest bar in terms of the level of assurance, but that was sort of the natural assumption especially with the changes made within it that NIH Today, there was some discussion about level three assurance but I thought one of the most noteworthy thing was the recommendation of having a process for coming to the level of assurance and not jumping to just the highest bar, which I think it's very important with what we're talking about.
I also had a couple of thoughts which are maybe a little bit contrary to their direction we are going. And one at that I think many people said, this is a problem that has dampened discussed, and I am just my own personal experience, thinking about Internet banking and how much very large-scale financial transactions are going on with no person per thing, I am very antecedent with% proving their but maybe there are lessons for us to learn. And we also looked at this issue three or four years ago and there was a lie [indiscernible] that we have no evidence. And we heard that again this morning and we really don't have any evidence which is puzzling. So this is a metric to determine the risk, really, we are speculating, and it is hard to make policy in that environment. But to the contrary, I tend to take that that is a consumer issue and not it's own problem solved. If I am not very comfortable pursuing [indiscernible] that a provider is the distinctive competence which justifies a month to be [indiscernible] is implicit in our discussion, if we are going to [indiscernible] within 2013 or 2015 with a relatively foreseeable time frame to be on this network not only as consumers or other providers, we should at least architect [indiscernible] that is the primary outcome and providers may be the first initiation of that and maybe there are some extra features that providers because of their licensing have, but on the whole, I am mayor is that they will be a structure that perpetuates an institutional structure that we don't much like and we should be wary of doing that as we developed this first solution.
I thought that was a very helpful round robin and without a lot of good ideas about --
As usual, it is great to hear all of your insights.
And this morning, I was at home with my own kids health care issues, but they are better now.
I guess that, I just make one observation about what I think is a slightly new wrinkle in the direction of our discussion which is to focus on intermediaries which interests me quite a bit.
The focus on intermediaries. Several of you made this point, and it strikes me that the maximalist solution here tends to want to envision perfectly constructed end to end architecture from the federal government all the way down to Hansard the patient but certainly two answer the individual provider, and that strikes me as the hardest way to look at a problem. It strikes me based on a what a number of you have said, if we look at how everyone contracts with providers, we can create almost sort of a safe harbor for everyone to start to get over [indiscernible]. And at the time you say that this is not a technology problem, I agree with you 100 percent. I agree that the trust and authentication and identity problems we have here apparently just social, where the community has to adjust, because the providers have to ultimately decide that day still trust so they don't face legal liability and I think for the trust for the government is to establish the sensible expectations about what everyone's liabilities are so they can proceed and mostly not worry about it.
So I think understanding the responsibilities, the obligations on intermediaries, whether they are providers themselves and whether they are standing in the place of providers, but when they are dealing with some unknown point out there, whether it is a pair for provider or lab or anyone else, that there is a cover level, which is kind of a generic point.
And I guess what I think that implies is that we focus a whole lot less on specific technical -- well, that we ought not two try to specify the technical behaviours of these intermediaries. But we ought to think more and a cutback to are four scenarios and think about the expectations on the intermediaries and, if we could clarify those with everyone that is expected to function in this community, [indiscernible] less worry. I think [indiscernible] because Interoperability is to introduce a baseline of certainty in a limited set of interactions. And it will grow and there are also questions that require people to buy it a little bit [indiscernible] but we won't know what those are until we get started with the next one.
They're is a policy committee meeting next Wednesday and I think we are invited to at least summarize how far we have come in our deliberations and if we are prepared to make deliberations we will have that opportunity.
What I have heard as kind of an emerging framework that we have talked about a little bit and reflected and it that is to go back to the use cases we have reflected, with the taping tools for our discussion that we are engaged to some degree, and maybe we should review those use cases to see whether they can be classified either across the board were with some great clarity in terms of these brisk levels and therefore the a seceded authentication with the proofer requirement. And that would itself be an educational exercise in itself with the policy meeting.
And I am wondering if the last suggestion that in a sense sent the speaking to this will stimulate some behavior in the market and might be helpful.
He pointed out was very thought-provoking, that most of the context here was remote access to complications and the potential to risk from that. This is something that has been bugging me for a long time, is the point that was made. If I am a physician working in an emergency room in that physical location, while having logged into the clinical application there, the standards that that organization has, the amount of risk and danger is enormous. I can supply orders were changed orders, the people's lives are literally at stake. I am in the system now, and yet, we are saying, if you want to send something, a prescription out of that organization, but at the risk level and say that the authentication is done to allow me to access the clinical the occasion and that is somehow now inefficient and I need to have a token, that doesn't make sense to me.
I would say, that is because that one of the things that does make this investment seemingly different, that would determine contextual authentication. We saw some of it, but the context, I think the example that was given to last, we got it in the emergency room and he is acting as a doctor and the people there are in the room and that provides its own level of authentication. So if we were going to provide a risk assessment, but those are the kind of things that we would actually come into it and then we would come up with what someone else might couple call a level one or two practice Institute in a much closer contacts. They're is a lot of context and health care, a lot of it, and it will change so that you don't necessarily have to have the same token to do everything that you want to do.
Another way to potentially think about it is the two factor, right, is what you know or who you know and where you are potentially, but the physical location on the networks. And on the network is my second factor. And if I wanted to remotely do this from home, then it now that is a different story. But if I am physically on the networks that will then use the server to server, then that is my --
Well public and make it quite that broad. It may be in at work on a particular task, because the task does matter. Not just that I am on the hospital's [indiscernible]. And another reason that we would have to look at context is simply with the back to workflow which is so intimately linked to the systems. Even if you have high compliance in terms of the high penetration and the number of people who are willing to by these systems, there are many things in their environment that are not going to be able to change, and there are these great stories from the Institute of Medicine study is that just came out when you talk to people that participated in the studies, one of the stories was, there were these three machines and in order for the service to be provided to the patient in a hospital setting, the doctor who is prescribing treatment has to be locked into that machine. But the doctor cannot physically be there because it has two timeout and so forth. So that nurses only job, for is to go around and make sure the right doctor is locked into the right computer. And there are lots of stories like that in their report when you interview them, and so the point is, maybe what we're really talking about when the data is crossing down is because you can't do too much inside of that organization's because you run into all of these legacy system problems.
What made me a little nervous was, to say, let's go run through the use cases and to the risk assessment that the NIST tool to have us do, and then applied as a risk assessments to come if you use a EHR -- If you use it for your clinical care than it does not apply. If you do then this higher level of authentication applies. And that is because it imposes new workflow demand that are not present.
Activity is just as risky when you do it within the walls, if you talk about the provider to pharmacy, provider to peer interaction that are currently taking place within the EHR, we're testing the vendor.
Let's take the provider to provider tier summary transition, because it is our simplest case. And I might send you through whatever mechanism or whatever invented we described here, but never ends up being the approved way of doing it, whatever in a way that we say, but it is certainly possible that once we send it to you, there could be authentication failure in that system and that Maris could actually be an identity thief or any number of things. And I will tell you that that is not the problem. It is a HIPPA problem and there are all kinds of other laws for which it is a problem, but I think the part, essentially I agree with you but I do think we are imposing making that as manageable as possible, but I think we should resist any security problems that don't directly to arise out of these scenarios. We have to assume that the systems are well enough to designed to handle those other problems, and if they are, there are legal or financial consequences or some kind of consequences for failure. And Tonya will tell us, I am sure, it's the thing that we suggest for Interoperability would end up creating a new security hole, then the existing ones, which shouldn't try to fix. I hate to say it.
Is it okay to assume that -- I am talking about the study that we heard at the last policy meeting which told us some frightening amount, like 63% of Healthcare's are not doing that they are supposed to do by law in HIPPA. And so I gather that might not be our problem in particular, but is it okay if we compounded the problem and give rise to another problem in that under that scenario, is it okay to accept that particular progress [indiscernible] they don't care to do one, but now they are introducing new problems on the network and creating other ones for everybody else. Is that okay?
It is not -- not doing something different for Interoperability. They could make the risk assessment part of meaningful use to address that more broadly than trying to be more secure on Interoperability [indiscernible].
I think we have to assume that there are state regulatory mechanisms, there are other sets of mechanisms which may not be working well, but the only way that we could possibly address those problems is to say that you actually can exchange data -- can't exchange data with another provider that they have not certified that they have met all of these other security best practices and requirements.
And their art environments where that is what happens, that is two a certain extent what banks do have it the way other networks work, they are not one to talk to you and your system will not talk to them unless you have seen their audit statement and all of that other stuff. I think it is a big step to say that we want to go there. I'd think it is a big step. And I guess we have to believe that --
Wellcome is the provider doesn't do that, it is not part of accreditation?
[indiscernible] doing the use cases and several people did not like that in terms of the risk assessment in the real rarity of the contracts and so on.
But Tanya said that context is part of the risk assessment. I think it is just a lack of knowledge about how this risk assessment would take place, and maybe in the organization, that is global to assurance needed. Assuming a different context.
Do we know enough about the risk assessment.
What Peter talked about, that is not something we should just casually to. These attachments that they were referring to are very sophisticated. And we could do a back of the enveloping, if they felt that there was enough variability there, but I don't think that is something -- I think Danny's point, that if we are really asking the question about, do we just shutdown Interoperability? We already have a level of Interoperability which is trivial in terms of the volume of data that can be passed, but nonetheless, it puts the trust requirement on the recipient. And if I faxed something to another's doctor's office, that either is the IS in the late building or a trust them. That is organizational trust, and we understand that when we greatly amplified the amount of data that can be spent that way, the consequences of casual organization or promiscuous organizational trust, if you will, get higher. But if we get this far into uncharted territory, in terms of the mechanisms for establishing audited trust organizations where we are sending information, then I don't see a way to meet meaningful use requirements in 2012.
Or the installed base for the EHR in that time.
Well, do we care about a EHR interactive was someone who may not have won a bet can get e-mail, I think that may be important as to whether we want to meet that criterion are not in this discussion, I don't know.
But fundamentally, we operate now in an environment that carries risks about information sharing, and we understand that we will amplify those risks.
That I am understand it, what is the best way to go forward, it is it to stop [indiscernible] and get to an unknown quality and technology at an unknown cost, or do we start again and try to find a middle ground?
I would be curious as to what the group thinks, are we talking about the meaningful use in the install base in 2011? Or are we talking about something else? I am not saying that it has to go -- and not talking about EHR to EHR, but does it come from EHR at least?
Well, it may or may not. I guess that, I would be happier -- my understanding is that there are different ways that providers interact with the existing payment systems. Many of them are able to interact within their own systems and many do that through the third party, but it would seem that our goal would be generic enough that any provider could participate.
But the analogy falls short, because when you are talking about pain pain risk 95 percent of the providers to have a system that they can submit from. We are talking about the situation where maybe 20 or 30 percent will have a system, so it is a different thing. And how you handle it once it comes out of the system is which you are talking about different ways to do it, but you're talking about a situation where 95 percent are already coming out of a system.
We are talking about the meaningful use cases, and the reason we are talking about those is because it is governmental responsibility for meaningful use as part of this certified use technology.
I was thinking for example in the case of the referral.
But again, you are not talking about 20 percent of the providers in the country who versus 95 to 98% in your example.
But we need to put some bounce around this.
Well I think that the change some of these discussions.
We are coming to the end of our public session time, and then maybe people on the phone who want to speak as well. Then we will adjourn this meeting and a few minutes and maybe other conversations can happen later.
Sell if there are any people that want to comment, but those wrapped up. That will come back to the broader questions, the findings of the committee and so on the leader.
So those of you that have your signs up?
What I was going to say, I was just like to clarify back to your earlier point about the risk assessment. But for us to move forward, would probably have to do some kind of back of the envelope risk assessment because even if we don't do it, we sort of do it implicitly and away, so it would be better if it was done more explicitly.
I agree on several things, but with regard to Damascus assessments, one of the things we heard over and over again is, we need to push this to the provider, and ultimately everything relies on a policy and contractual framework of the attraction. And at the end of the day what we care about, I received information from provider A. I need to know that provider A, that is truly does come from provider A and provider of A [indiscernible]. And at the end of the day, I don't believe that we can over policy this, except by pushing this down to the organization and authenticating the provider and making sure there is some legal teeth to the policies that provide that organization implement and making sure there are legal teeth to the contractual relationship that that provider has to that organization, and that is those three things are in place, you have a certificate that you can sign on the transaction, if consign the transaction such that provider A Can [indiscernible] provider B. So I would like to sidestep a lot of this risk assessment discussion to what I think is the more germane discussion about what is the right policy framework for an organization contractually to apply in authenticating the providers.
I think I am struggling with a question we are trying to answer a little bit, but going back to the premise that provider A Thoughts provider B the summary, it seems like there are three things we need to consider. One is, are they who they say they are? And another is, are they helping to automate that function, because governments maintain the National Fire and maintaining hundreds of millions of dollars against the database, then we should consider it. In other words, a way to validate the real provider. And what we did in Katrina health, we essentially used the a and a master physician index in a similar way, which was that we had a lot of information where they could do knowledge based education for providers, and that worked. So I need to know who they are. I need to know they have a valid certificate from a valid issue where that I can trust, and the next one is the biggest challenge, they need to police it. I need to have mechanisms for oversight and redress, and the regulatory and legal free-market, if I am a physician and licensed and subject to fraud and abuse laws, it is very different than what an individual might be subject to when they are on the Web. And I think that makes a big difference.
One of the reasons I was pressing today in the questions about oversight is that, to someextent [indiscernible] the initial part, what they would be. And I think I would want to send the document to someone and know that I was sending it to the right person.
Annie flast comments before we adjourned?
I am afraid I will perhaps redundantly repeat myself, there is a difference between sending transactions over a network and getting remote access to an application.
Virtually everything we are talking about in terms of stage one Interoperability criteria involves sending something over information, even to BioPharma ePrescribing. For example [indiscernible] and there we have an obligation to make sure it is audible. We don't have an obligation to pass the trust to the other system and I think it is important that we keep that in mind. All.
I'd like to test the temperature of the group in terms of, how many folks think that intermediaries need to be a part of the authentication story?
So one alternative would be centralized credential and at every provider.
Are you talking about like an independent third-party that would be part of an authentication and proofing process? War instance, as a part of the hiring process, most hospitals will go through and I9 process, and do a certain level of required by Kennedy proving as well as an employment eligibility check.
Well, what I am talking about is, do we try to do authentication. The provider, and the provider when something, the provider hold something has to have a token or a PKI, the provider has to have something, or do we think that for the for meaningful use use cases we are talking about here, we think the certificate holder can be the information service provider, and the authentication is delegated to that information service provider, without requiring that the and the user poll the hard token.
That question has so much stuff embedded in it. Every one of those has lots of options. You just took one pass through lots of options.
Let's look at this the same way we have looked at me polices itself, which is, that is a three tiered progression along a trajectory that may start at a relatively modest level, and that may step up to a higher standard as time goes on. Of course, that carries with it the very real risk, given away the incentives are structured, there will be providers that on average it past the first level. But certainly moving from a less robust authentication, and perhaps I Kennedy proofing strategy to a more robust strategy overtime, and framing our recommendations within that context, I think would be appropriate.
It may be premature or complex to answer your question anyway, but I think giving our timing and where we are at this moment, it would be helpful if that staff could collectively sympathize today's testimony and not necessarily report it back but have collapse it into categories so we can collectively take a look at those and decide which are the latest embedded into these pathways that we talked about. We will need another dive analytically into the complexity of the problem. And we normally have a tool that we can do that, through more conversation but we are out of time. But my request would be that if the staff could come back to us in the next few days with something, that would be a good suggestion.
If would be good if we could have some simple high level recommendation pertaining to authentication for next week. That would be good. It may not be possible, but it may be good.
How about if authentication is needed? [laughter]
Those Maybe such high-level findings in the summary that it could be fairly obvious. And it would be good to remember that the policy committee as a whole and the other audiences haven't had that much exposure as a whole, and would probably see things that are more clear that were not clear three months ago.
Any more comments?
Without any further discussion, we are adjourned for this meeting. We thank our guests for today, we are adjourned.