American Health Information Community
Confidentiality, Privacy, and Security Workgroup Meeting #9
Thursday, April 12, 2007
Disclaimer
The views expressed in written conference materials or publications and by speakers and moderators at HHS-sponsored conferences do not necessarily reflect the official policies of HHS; nor does mention of trade names, commercial practices, or organizations imply endorsement by the U.S. Government.
>>
Okay. Judy, we're ready to get started.
>> Judy Sparrow:
Welcome everybody to the meeting of the Confidentiality, Privacy, and Security Workgroup. And just a reminder that we operate under the auspices of the Federal Advisory Committee Act which means that the meeting is being Webcast and minutes and transcript of the meeting will be available on the ONC Website.
Also, for those of you that are calling in, please remember to speak clearly and distinctly and identify yourselves before you speak so we can attribute your comments in the minutes. And also when you're not speaking, please to mute your telephone to reduce the noise.
I've got a couple of announcements. We have a new member of the CPS Workgroup, Sylvia Au, who is the state's genetic coordinator from Hawaii. I believe she's on the phone and Sylvia, could you take a few seconds and briefly introduce yourself to the Workgroup?
>> Sylvia Au:
Aloha everybody. I'm Sylvia Au and I am on the Secretary's advisory committee on genetics, health, and society and Jodi was kind enough to give us a briefing at our committee meeting last month, and we've been dealing with some of these privacy and security concerns, of course, since we deal with genetics.
And Jodi invited a member to join, and I was the one elected to join and help you with all of this stuff that we've been trying to deal with. So I look forward to working with the group and it looks like you guys do a lot of work.
>> Judy Sparrow:
We do, and thank you, Sylvia, for agreeing to do this. One other thing I want to point out is that the June meeting of the CPS Workgroup, unfortunately we’re going to have to change that date from June 28th and we're suggesting Tuesday, June 19th. I just want to bring that up now to you and we can talk about that at the end of the meeting. But we're going to probably have to do that.
So Jennifer, why don't you introduce who is on the telephone and then we'll go around the room here and then Kirk can begin the meeting. We have kind of a long agenda here today with two panel presentations.
>> Jennifer Macellaro:
In addition to Sylvia Au, we have David Wright in for Steve Davis from the Oklahoma Department of Mental Health and Substance Abuse Services. Elizabeth Holland from CMS. Tom Wilder from America's Health Insurance Plans. Peter Basch from MedStar Health. Deborah Parris in for Flora Terrell Hamilton from Family and Medical Counseling Service. Dan Rode from AHIMA. John Houston from the University of Pittsburgh Medical Center. Sarah Wattenburg from SAMHSA. Gail Belles from the Veterans Health Administration, and it looks like Mark Kennedy, one of the presenters, from RxHub.
Did I miss anybody? Okay.
>> Judy Sparrow:
Now we'll go around the room. Paul.
>> Paul Uhrig:
Paul Uhrig from SureScripts.
>> David McDaniel:
David McDaniel, Department of Veterans Affairs, Veterans Health Administration.
>> Sam Jenkins:
Sam Jenkins, Department of Defense, TRICARE Management Activity.
>> Steve Posnack:
Steven Posnack, Office of the National Coordinator.
>> Kirk Nahra:
Kirk Nahra, Wiley Rein.
>> John DesMarteau:
John DesMarteau, LAXOR.
>> Philip Marshall:
Philip Marshall, WebMD.
>> Ken Majkowski:
Ken Majkowski, RX Hub.
>> Alan Harvey:
Alan Harvey, Massachusetts eHealth Collaborative.
>> Amy Zimmerman:
Amy Zimmerman, the Rhode Island Department of Health.
>> Deven McGraw:
Deven McGraw, National Partnership for Women and Families.
>> Judy Sparrow:
Okay, and we'll turn it over to Kirk.
>> Kirk Nahra:
Good afternoon, everybody, and welcome to the next of our series of hearings. Before we get into the substance of today's session, I want to point to people both in the room and on the phone, the summary of our last public meeting on March 15th, kind of a long summary. I don't know if people have had a chance to take a look at that. Are there any comments or questions about that summary at this point?
Okay. Do we need an approval motion. Not really? Okay. If people have it, as they read it over the next couple of days if they have any questions or comments please let either Steve or me know and we'll make sure those are taken care of before this gets finalized.
>> John Houston:
This is John Houston. Can I ask a real quick question. What's the room number for the Web?
>> Steve Posnack:
John, it's www.hsrnet.net.
>> John Houston:
I got that. There's a room number.
>> Steve Posnack:
8285166.
>> Kirk Nahra:
Did that work?
>> John Houston:
It did. Thank you.
>> Steve Posnack:
You're welcome.
>> Kirk Nahra:
Good. All right. Why don't we, just trying to keep on schedule, why don't we turn to the substance of our presentations today. Just as a reminder for the Workgroup and for others who are listening, our goal today is to try to address some of the issues that have been raised in connection with what we've been calling our working hypothesis, which has been the topic of our last couple of discussions related to looking at the wide variety of entities who are involved in health information exchange projects around the country and to look at how they are currently regulated, not regulated, with an eye towards making some recommendations about what that future state should look at.
And what we have today is that we have two panels who are involved in sort of different pieces of the industry. And we've got - let me just layout how we're going to proceed today. We've got two different panels. Each of the panelists has been asked to make a brief presentation. We will have some initial time for question and answers, although I want to keep that relatively limited so that we can make sure that we get to all the panelists today.
We then have some time set aside after the presentations for the Workgroup to have some discussion about the working hypothesis. Most, I'm not sure if it's all, but most of the panelists will stay around for that period of time so we'll have time during that period for questions and discussion as well. Again I want to make sure that we can cover as much as we can through the prepared testimony.
So with that, why don't we turn it over to the first panel? Steve, do you want to introduce them?
>> Steve Posnack:
Sure. For the personal health records panel we have John DesMarteau, close enough?
>> John DesMarteau:
Close enough.
>> Steve Posnack:
And Philip Marshall from WebMD Health. I guess I'll turn it over to John to go first.
>> John DesMarteau:
Thank you. Just a little background on myself. I was with Kaiser Permanente here in the Washington area, and with Kaiser one of the roles that I had was I was a physician director of HIPAA. So I am a recovering HIPAAholic. You're going to do the slides? Okay. Obviously people in the general population are concerned about privacy and security. It's a somewhat now dated study but the Markle Foundation found that 91 percent of people were very concerned about the privacy and security of health information in a study. Although people that had chronic disease and that were high percentage users were somewhat less concerned. The other thing is that, living here in Washington, almost every other day there seems to be some major leak, primarily, sad to say, from within the government lately, the IRS with their stolen laptops, et cetera. And I think there was another leak down in the south somewhere recently. So people are quite concerned about this area. Having said that, it's always interesting to me as a physician how readily people in the general population speak about their health issues. Next slide.
The fact of the matter is, however, that if we look at HIPAA, which perhaps is a defining benchmark in terms of privacy and security, certainly has had a lot of effort put into it by both public and private institutions, most of the current crop of personal health records are not defined as covered entities. And I'm sure the committee knows that. Some obviously would be, like, for instance, if a personal health record was sponsored and promoted by a health plan, then presumably that personal health record would be a covered entity. I have decided to try to answer the questions based on what we're doing, which is what I thought the committee wanted to hear so we could go to the next slide.
So these are there were 13 questions that Steve sent to me by email. And so I tried to answer them. In terms of the collection and sharing of information, the LAXOR personal health record is patient-owned and patient-controlled. So in order for access to be given to people and entities that are not the patient, is not the patient, the patient themselves or their legal representative must invite providers. They must also invite other family members to be involved in the record. And we have a role within the LAXOR personal health record that we call personal health information managers. And for people who are involved in public health, you can think of these people as being a form of case manager, although they don't actually prescribe treatment or, it's more to facilitate communication and the maintenance of the record. They don't generate the record. Next slide.
In terms of collection of information, which was one part of this, we have a number and I won't read this slide. But we have a number of ways of getting the information into the record. At this point in time, since clinical EDI standards are in process but have not been promulgated to say the same extent that the HIPAA standard transactions have been promulgated and thereby the syntax and all the IT requirements defined, we have focused on the fact that a lot of information is still on paper. And in some ways paper is much more difficult to control than electronic information, in some ways. Next slide, please.
So sharing of information, I've mentioned this, that access has to be established by the patient. There is access in our system for both routine and emergency, and the emergency access is a data subset, unless the patient wants to authorize a wider access to the data. Access is time can be time delimited within the system. However, because our system is not only consumer-centric but also is, has a provider access component, providers always have access to the data that they created. We have backend systems that identify who created the data and when it was put into the system. Next slide, please.
For protection, well, obviously one of the things that we felt needed to be done is that hosting needs to be in a tier-1 facility. Whether that facility is a private, is privately owned and managed or is part of, say, a RHIO, should they happen to be large enough to get into that business, it should be a tier-1. And I don't know if any of the committee has ever been to a tier one hosting facility. But you might want to call up Equinex locally and ask for a tour, because I think you'll be quite surprised at the level of security. You will have to find someone, and perhaps it could be LAXOR that would allow you to get in. Because you just can't walk in there. Obviously hacking is a very, is a very crucial point. And in this, I think the third bullet there, database encryption, it just boggles my mind that, for instance, there would be data that the IRS would have on any one of us sitting in this room that would be sitting on a laptop that's not encrypted. I mean the one you know, forget about your health information. How about identity theft? Social Security number. All your tax information. You might as well just put that out on the front lawn and say, here, come and get it. Another component is loss of data. And obviously there you need companies that are involved in this should have colocation with mirroring of the data, not to say that it still can’t happen. We do not store Social Security number or credit card numbers. That's another because again we're not only concerned with loss of health information, but identity theft. Next slide, please.
I think one of the things that's paramount for this whole industry, considering this is a fledgling industry, if there are any breaches that clients be notified as soon as the breach has been identified. We feel very strongly about that. I know our time is limited here. I think from a standpoint of physical and technical safeguards, as I’m sure you know, in the security regulations there's three areas, administrative, technical, and physical, that under the latter two, there needs to be repeated threat analysis and threat testing. Those are important components. It's better to identify something and deal with it, especially, again, given that this industry is in its infancy and a major privacy breach, security breach would be very, very detrimental.
The next slide, please. Obviously everyone has notice of privacy practices. When I was at Kaiser, was very much involved, and actually if you go into any of the Kaiser facilities, the poster that you see hanging up is a poster that I designed. It has to be in plain English. These multipage privacy notices that no one reads, I mean I get them all the time from insurance companies and stuff. It should be fairly straightforward. And it should be downloadable so that people can actually download it and read it. It should also be both in the public Website and in the personal health record itself, and by the way, those would be HIPAA requirements if at some point PHRs were determined to be covered entities.
Next slide, please. So a question was about consumer control. And in this I think I've spoken to the first bullet, but the second bullet, there was if you look at HIPAA, one of the concerns is the ability to append or amend, as they call it. And there's a whole request for amendment, denial of request. Rebuttal to the request. And it gets very complicated. So what we chose was we allow patients, because this is their record, and I think personal is the important point, is that patients can post comments. So if the doctor writes John DesMarteau is a fat slob who doesn't look after himself I can say I'm not a fat slob I weigh 155 pounds and I'm 5 foot 11, so I don't think that defines me as a fat slob. Now I may be slovenly in some things, but I'm not fat. However, an Important point, especially for PHRs that have a relationship with providers where providers are putting in information is, if there's going to be data integrity, patients cannot change that information. I may be saying a lot of things that are obvious, but it’s --
Okay. Next slide. Operation of law. Well, for the most part, especially personal health records not connected with health plans like, for instance, Aetna, has been taking out full-page ads in the Washington Post here about their personal health record. LAXOR is not a covered entity as it's defined. It's not a health plan. It's not a healthcare clearinghouse. And it's not a provider. But we decided right from the beginning to follow HIPAA where it was appropriate to our business operations. And I'll get into that in a minute.
Next slide. Now, there was a question about whether we, what we felt about competitiveness. And we think that it increases the perception of LAXOR's trustworthiness in the public. And so we think that's important. We also think that from not just looking at the public, but also looking at providers and providers covers a wide gamut of entities and individuals, that it could facilitate interoperability, even if interoperability at this point is simply faxing in documents. Because again it increases trustworthiness. And I think this becomes very important if a PHR is trying to have a relationship with, say, a Kaiser Permanente.
Next slide, please. So on this particular slide, I think I'll jump to the third major bullet point. We do not feel that the costs outweigh the benefits. And I think I've covered that.
Next slide, please. Now, there was a question nine was so if you're going to follow HIPAA, what's the minimum privacy set? And again I'm not going to read through this. I've quoted the section, and this is in the updated HIPAA regulation. So this is not from the 2002, excuse me, the 1996. This is from the 2002., but the sections are pretty much the same. So again I'm not going to read through all of this, but we feel that the ability to amend with the provisos I've already spoken about. Access and right of restriction. Business associates, and I'll get into that in a bit more in a moment. Complaint management. There needs to be a complaint process in place. And these are sort of the basic tenets of the HIPAA complaint management.
The next and now disclosure accounting. We don't call it disclosure accounting. But the LAXOR PHR has a builtin audit trail that shows absolutely any time anyone accesses the record, and if it's someone other than the patient. So the system knows that it's the patient or the patient's legal representative who is logged in. If a provider wants to access the record, they have to give a reason. And usually, hopefully that reason would usually be direct patient care. HIPAA training is important. Limited, obviously if a PHR wants to work with a third party in terms of data usage, then the data should be de-identified unless a patient has been given a specific opt-in authorization. Marketing is pretty obvious. The minimum necessary rule: only that which an employee needs to know in order to do their work. Notice of privacy practices and policies and procedures.
And the next slide actually has a picture of, which you can't read from probably for the most part. But this is absolutely every so if I were to log in as, this case, the dummy patient, John Q. Public, it will show immediately as soon as I logged in if I go to this screen that I have logged in, and it will say member selfmanagement. If a physician were to be accessing the record it might say direct patient care. If a personal health information manager was accessing the record in order to do some administration, it would say administration. And this covers the HIPAA requirements. Who, why, when, and what.
Next slide, please. A couple of non-relevant HIPAA principles. Authorizations, because this is a subscriptionpaid service, people have to agree to the terms of use. And we consider that to be our authorization. So we spell out in our terms of use the ways the data may be used, and also in our notice of privacy practices. The other thing is we're not running an outpatient surgery center so we don't have facility directories. So these were a couple of things that we scratched off the list.
Next slide, please. Certification process. The question was, would we be interested and willing to submit to a certification process. And from our standpoint that would depend on the requirements. We’d like to have, if there was a process, I think that there needs to be at least a couple of public personal health record companies at the table as these are described, and not suddenly present us with a fait accompli. The cost needs to be taken into account of both initial compliance and subsequent compliance. And then that brings up what is the periodicity of the recertification process. And then lastly is there going to be any value to doing this? Is the DHHS or another government, perhaps the Office of Civil Rights in conjunction with DHHS, is it going to promote this as a standard?
Next slide, please. Market forces. There was a question about how this might impact us in the marketplace and again I'm not going to read this slide. But I think the last, you know, the whole point about liability and consumer trust, this is still a nascent industry. And again I have to emphasize if there was a major mishap on our part, it could destroy us. I know that a colleague from WebMD is sitting next to me. WebMD is a very big company but it could destroy any company's foray into the personal health records, or make it much more difficult. So it's very important that we think about privacy and security.
The next slide. I said I would talk a little bit about business associates. We're not actually in any what we consider to be pure business associate arrangements at this point. But we have basically assumed that we would be treated as a business associate if, for instance, of a Kaiser Permanente or a public health plan or a public health institution and therefore we have actually got business associate contracts ready from our standpoint, we would have multi, multi pages, about 50 pages long, that goes into every aspect. We would assume that we would have to sign one of those, so we're not afraid of that particular aspect.
Next slide. We do have one subcontractor at the moment that is providing our hosting in a couple of different locations. And what we have in place, since they are, in a sense they're not really a business associate as defined by HIPAA. They're more like the telephone company, they’re the pipes that transport and store. We have an extremely robust confidentiality agreement. And, again, they are a tier-1 facility. And that's the end of my presentation.
>> Kirk Nahra:
Thank you. In the interest of time let's move on to our second presenter and then come back and have some questions for both of the presenters after that.
>> Philip Marshall:
Sure, my pleasure. Good afternoon everybody, my name is Philip Marshall, and I'm vice president of product strategy with WebMD. Thank you so much for your questions, posting those to us beforehand so we could answer as many in our prepared testimony and happy to answer additional questions as time allows.
So WebMD Health is the leading provider of health information services, serving consumers, physicians, healthcare professionals, employers, and health plans through our public and private online portals and health-focused publications. Through our health sites, including WebMD Health, MedScape, MedicineNet, eMedicine, eMedicine Health, RxList and theHeart.org, and others, we reach more than 35 million visitors each and every month. WebMD health is a subsidiary of Emdion Corporation. We have been asked today to discuss the role of personal health records as part of an emerging environment of consumer empowerment within the U.S. healthcare system.
Our experience with providing PHR solutions to consumers and employers and health plans has shown that PHRs can be a vehicle for consumer choice and can serve as a bridge across a fragmented healthcare system. Moreover, as consumers are better able to gather, store, and make available information from multiple providers, multiple systems, and data sources, the PHR will better support improved treatment, benefit and provider decision making, and enhance communication with healthcare providers.
The key points that we feel are important to today's discussion include the following: Although a PHR can be created in a variety of ways using a variety of data sources, the objectives really remain the same. And they are to enable consumers to gain insight into their health history in order to provide a better context for decision making, to enable care providers to have the essential actionable health history available in order to make clinical decisions, especially when a clinical record on that patient is not otherwise available, and to support the continuity of care for consumers as they move across the healthcare system.
WebMD Health’s personal health record products and services are designed to collect information electronically on behalf of and at the direction of the consumer, from any data source available in the continuum of care. To date that's included health plans, providers, pharmacies, laboratories, and other thirdparties such as pharmacy benefit managers or PBMs, as well as, of course, from consumers themselves. In order to maximize the value of PHRs to consumers, consumers must be able to access that information and obtain it in a format that can be used to populate the PHR application.
The utility of PHRs we feel is tied in part to the ability of a consumer to retain access to that record over time, which may require access across care providers and physical locations. In this regard, WebMD Health recognizes that user authentication and data portability are essential issues to resolve. On the issue of user authentication, the ability to validate a user's identity we feel is critically important to the success of PHRs and the security of the data stored therein. There are a variety of tools currently in use today to authenticate users and the level of authentication should be commensurate, we feel, with the level of PHR access provided and sensitivity of the data at issue. On the issue of data portability, we feel thAT portability is critical for helping the user to create and maintain a longitudinal consumer-centric record that can support healthcare consumerism over time. It will require mechanisms that appropriately and securely contain the person's identity as well as allow for the exchange of data as well.
Point number four. The widespread adoption of personal health records will be based, we feel, in part, on the confidence that consumers have in the privacy and security of their information. WebMD Health protects the information it holds, stores, and transmits through privacy protections that empower consumers to make decisions about whether and how the information may be used and/or disclosed. Our policies are posted and easily accessible on our Websites. We also take a defensive multilayered approach to securing our Webbased tools by implementing complementary security protocols at the physical, network, system, and application layers. We protect the health information we hold, store, and transmit in accordance with the law and at a level that meets or exceeds industry standards. We also make available to our customers a security practices technology brief that describes our approach to security.
Point number five, PHRs, first and foremost we feel, are a product for consumers. As such, applicable laws might include, and by the way I am not a lawyer yet, so I'm reciting the laws that have been shared with me apply here, so bear that in mind. Federal and state and consumer protection laws. HIPAA in some limited circumstances. Gramm-Leach-Bliley may apply to PHRs offered by financial institutions including insurance companies. State security breach notification laws and law of contracts for compliance with terms and conditions.
The setting of an industrybased standard providing a minimum set of security principles and protections of PHRs would help to advance the use of PHRs, we feel. In doing so it will be essential to strike a proper balance so that appropriate privacy protections are assured while avoiding rules that would unnecessarily and inappropriately restrict the development, utility, and uptake of PHRs, and in particular I might add, and I feel this is very important, any rules that prevent consumers from being able to gather and store data to ensure that their data is available when and where it is needed could unnecessarily stifle the positive effect that consumers can have on the efficiency, costs, and quality of the healthcare system. These issues are under consideration, as you know, in Congress and HHS, and in addition a number of advisory groups are looking at the issue. And those are listed in the prepared remarks.
And so to close, the conversation that we're having around personal health records we feel is extremely important. It's healthy and productive. And the work that the AHIC and its Workgroups have been doing in bringing in key stakeholders together to move the process forward we feel has been very helpful. And we very much appreciate the opportunity to share our point of view with you, and we'll be happy again to answer additional questions as time allows.
>> Kirk Nahra:
Great. Thank you very much. Appreciate the remarks from both of you. Let me ask a couple of questions to get started.
Let me start with questions for LAXOR. Can you give me just a short description of what the company actually does? I mean so the company I understand a lot of the practices, but you offer this product, sell a piece of software. Give me a sense of what you actually do.
>> John DesMarteau:
Thank you. Actually what we are selling is a service of which the software is just a component. The service is, as I mentioned, is a software component, but also on top of that is a whole communications infrastructure which can be managed either by the consumer themselves, if they're technically up to it, or by our personal health information managers, which as I mentioned before some people can think of them as sort of a case manager. I think you might want to think of them as the AHIMA's registered health information administrators. RHIAs rather than RHIOs. So what we do is we help people store the information, categorize the information, retrieve the information, share the information, and the people are consumers and their providers. And consumers could be subdivided into the patients themselves or family members. And family, when you think family, don't necessarily think biological family. But I'll give you an example. If you look at the largest cohort of people moving through history right now, which are the baby boomers, a lot of the baby boomers have elderly parents, and elderly parents may live in Sun City, Arizona and someone sitting at this table is working and living in the metropolitan Washington area and mom breaks her hip and has a whole bunch of medical problems.
So it's not just a question in our view of simply having an online repository. The other thing, and I don't want to belabor this, but the other point is I am a physician. I've been in clinical practice for more than 30 years. Even the brightest people who are not physicians become it's almost like they become stupid when it comes to medical things. I mean, they might be head of the Trident Missile Program and be extremely bright; but the moment you start going down the medical thing it's like their IQ starts to fall off. And it's partly the jargon but it's also the fact that even with the Internet where people can go to places like WebMD and get this fabulous range of knowledge, it's not just having a piece of information, it's connecting the dots. And I think that's what scares people. They're afraid of missing things. Doctors are afraid of missing things. So what LAXOR is attempting to do is to be an intermediary between this vast array of information that should come to bear at critical times when a patient needs care, and the patients and the providers.
>> Kirk Nahra:
Let me just ask a couple questions, two questions of Mr. Marshall, then I'll open it up to the group for a few minutes.
You were describing WebMD's personal health records product and also a variety of other things that the company does, a large variety of things the company does. Are they all linked up or is the PHR sort of a separate piece from the rest of the WebMD system?
>> Philip Marshall:
So WebMD provides a network, if you will, of public and private portals for a variety of stakeholders. Our health and benefit manager product, which sits at the core of the portal but also is by and large the product that is sponsored by employers and health plans, by large employers and health plans, has at its core a secure and consumercontrolled profile that is managed through the personal health record which we define as an application that helps the consumer gather, store, manage, and share their essential health data. Did that help?
>> Kirk Nahra:
I guess if I'm a WebMD user, I am one of the 35 million people that go to your site, and I do a variety of different things, does that all get combined in any way or is the personal health record is sort of here and whatever else I do on your Web site is somewhere else?
>> Philip Marshall:
When a person interacts with WebMD, and I'll use the example of private portals that we deliver on behalf of large employers and health plans, they log into a secure environment in which their data collection activities do get manifested in the personal health record. And as part of that process, and as part of that service, the personal health record does in fact always fall under both the terms of use, certainly the privacy policies that apply as well, and the user has a variety of options on how they might like to gather the data and share their data.
>> Kirk Nahra:
I had another question I'll save until later. Any other folks in the room have questions, again, we’re going to come back at the end to have some discussion and some additional questions, but is there anything -- Deven?
>> Deven McGraw:
I have a question for LAXOR. The piece about the provider always having access to the record, juxtaposed against the consumer controlled piece. I need to understand, I think, a little bit more about how that works, what kinds of consents do patients give to their providers that allows the provider to access it at all times when they want to unless I misunderstood what you said.
>> John DesMarteau:
It's actually the provider has access to the, when the provider it's rolebased access. So the provider, say myself, as a physician, could also be a patient. If I log in as me, provider, then the documents that I put into the system, there's technical ways of tracking all that. Those particular documents I have access to. But if I then, say you're coming to see me and you decide you don't like me anymore and so you fire me as your doctor, it happens all the time. So you go across town now you're seeing Dr. Harvey. Then Dr. Harvey now starts putting in information, his office starts posting some information. Let's say we're both solo practitioners because let's face it, there’s still a lot of people, not everybody is working for Kaiser in this country. Hundreds of thousands. So when Dr. Harvey, when you decide you don't like me anymore, supposing for argument’s sake I have put there's been some messages. There's been some communication, and now you turn around and sue me. Okay? And some of that information I may, I have put in the record. Well, I have the right to access that information. What I don't have the right, and because of the way we've got the technology, and once you shut me off, Dr. Harvey's notes, I cannot access them per se. Can you change them? No. No.
>> Kirk Nahra:
Can he change his own? No. Can you change what you put in?
>> John DesMarteau:
No, once a document is in the system, it's in the system. I can make, I can append. And that's one of the when you're looking at perhaps one of the things that you might I shouldn't this is where I get passionate because I've been involved in so many aspects of this. But when you're thinking about personal health records, also electronic medical records which are a whole different animal, they have ways they operate. And for instance, Kaiser is putting in the biggest private electronic medical record in the country. It will serve ultimately 8.3 million people. Bigger than the VA. If I were writing a note and then I want to change something, like there was some new information, I do, and it's called an addendum. And that's what it's called. So you see the original note and then you see an addendum. So we took care of that with comments. So our comments and the comments can come from either the physician, if the physician does not want to post a brand new note, or the patient.
>> Kirk Nahra:
Other -- yes, Sue?
>>Susan McAndrew:
One quick question. And it may largely be for LAXOR. As a HIPAA volunteer
>> John DesMarteau:
My condolences.
>> Susan McAndrew:
Just a question. What do you think you get from that? Is it just being able to use HIPAA as a standard for a certain level of privacy protections, or because there's no enforcement? You're volunteering for HIPAA is all nice and good but it doesn't make you liable for the HIPAA penalties. So it just being able to say that you meet a certain standard or do you think customers are really looking for their ability to enforce those promises against you?
>> John DesMarteau:
I think it's really, my answer for that or our answer for that is really two-part. I think the second part is that it does a lot of people really don't know what HIPAA is. Probably everybody has heard the term but they don't really know what it is. But at least it is a standard that someone can go and look up. That's part one. The second part is it didn't cost us a nickel to devise we can talk about the privacy aspect, which I think has been mostly administrative, but the security part is very nicely laid out. It's very rich. And from the standpoint of trustworthiness, because we really think that this is key, and I think that anyone that's doing personal health records, consumers have to feel that the information is safe.
And, again, long history, but we all remember Tonya Harding and Nancy Kerrigan. Well there was a famous case, this is in the public record, where Tonya Harding broke her ankle and was in a hospital. Actually I believe it was in the northwest. And she was in a Kaiser facility. And 100 people looked at her medical record. Now, I can guarantee you those people did not have a need to know. Well, think of it, we're in this city where there's a lot of VIPs. They may start having personal health records. Do they really want to know that they've been treated for fill in the blank? So we think it's very important.
>> Kirk Nahra:
Let me ask quickly are there any questions from people on the phone? Do we want to turn to our next panel?
>> Peter Basch:
Kirk, this is Peter, I have two questions for the gentleman from LAXOR, if I may. First of all, this may be the easier question. You spoke briefly about the implication of liability on this nascent industry. What exactly were you getting at with those comments? Were you suggesting that we need to be careful about liability protection for PHR vendors? Or were you just making a general comment?
>> John DesMarteau:
A general comment from the standpoint of putting in place as many reasonable safeguards as possible so that there are not either intentional or inadvertent breaches. At the same time, what Mr. Marshall said I think is very important. In considering all of this, and it's in the slides that I prepared, you've got to balance access and interoperability, because otherwise you sort of kill the whole concept of a personal health record. The phrase that we use is that the data should revolve around the patient, not the patient being revolved around the data. And I think that's really the key. Does that answer your question?
>> Peter Basch:
Not really, but that’s okay, let me just go on to my next one, which is on the issue of patient control. I think this you explained very well in your presentation and slides that there's a patient ability to append documents and control access. The question I had was, that said, can a patient grant access to selective components of their PHR, in other words, two of the labs or one of the documents or one of the medication history lists, so that what appears to be full access is actually painting a partial picture.
>> John DesMarteau:
Yes.
>> Peter Basch:
Okay, thank you.
>> Kirk Nahra:
One last question then I'd like to turn it to the next panel. Just a reminder for people both on the phone and in the room. We are going to come back and have questions and discussion for both of the panels at the end.
>>
By the way there's quite an echo on the phone.
>> Paul Tang:
This is Paul Tang to ask a question of Phil. Hello.
>> Kirk Nahra:
Go ahead.
>> Paul Tang:
And I'm sort of listening, participating from the Consumer Empowerment Workgroup. The question for Phil is I know WebMD is the largest provider of a number of services. One of them is PHRs for independent consumers coming on to their Website and the other, as Phil pointed out, for employers and their HRAs and PHRs. Does WebMD make any additional use, share, disclose, sell, any personal data whether it's identified or not?
>> Philip Marshall:
We do not sell any data identifiable, certainly not, or not identifiable. The data within the personal health record, upon the consumer's discretion, may be shared with care providers or other service providers.
>> Paul Tang:
Are you saying that the information that patients fill in in their HRAs for employersponsored programs is not shared back to the employers?
>> Philip Marshall:
The data is not sold. Upon the consumers, again, opt-in for our terms of use, the data can be made available in aggregate form for analytic purposes, which is completely de-identified. This is, for the purposes of a personal health record, of seeing who is, and how many people have come in and utilized the personal health record. And so when it comes to the PHR today, it is at an aggregate level for utilization purposes.
>> Paul Tang:
So in the terms of use as you register for the site, is it, would you have to agree for that to happen? That is, for WebMD to be able to share aggregate data with others, in order to use the system?
>> Philip Marshall:
So our standard, and I would have to go back and review the exact language, I believe our standard terms of use and privacy policy do say that deidentified data can be used for aggregate reporting purposes for our sponsoring organizations.
>> Kirk Nahra:
Why don't we at this point move on to the next panel? And again we'll have time for more questions and discussion for each of the panels afterwards. But let me move on to our panel two, which is on health information exchanges, and why don't we start with Paul?
>> Paul Uhrig:
There’s a chair over there for me, but unless it's a breach of protocol, I'll just stay where I am.
>> Kirk Nahra:
Stay where you are.
>> Paul Uhrig:
Thank you. I don’t know if I’ll be smarter if I move over there, but I’ll stay here.
Thank you very much for the opportunity to provide some testimony. My name is Paul Uhrig, and I am the general counsel and chief privacy officer of SureScripts. Normally I travel with a slide deck about 80 pages long to show who and what we are, but today I think I'm just going to speak for a while. Some of the people are going to follow me have some slides that very nicely sort of display their models and there are a lot of similarities. So I think you'll get some good graphic depictions of what these networks look like in some subsequent testimony.
As a background on SureScripts we were founded in 2001 by the pharmacy industry through the National Association of Chain Drug Stores and the National Community Pharmacists Association. They're the two trade associations that represent the nation's chain and independent pharmacies.
Our mission simply is to improve the overall prescribing process through the use of health IT. We created and operate a network that ensures, among other things, neutrality, patient safety, privacy and security, and freedom of choice of a patient's choice of pharmacy and a physician's choice of therapy. The network is known as the Pharmacy Health Information Exchange. Our initial services, which were sending and receiving electronic prescription transactions, were first put into production in January of 2004. It's similar to a network that connects banks with ATMs. Basically we allow for the seamless connection of physicians and pharmacies on a real-time basis. We allow secure transmission of prescriptions from the computers at the pharmacy to the computers at the physician and back and forth. A complete, and since it's not handwritten, legible prescription is sent all in seconds even before the patient has left the office. And therefore would be waiting for the patient when she arrives at the pharmacy of her choice. We don't develop, sell or endorse any electronic prescribing applications or software. Rather, we just certify applications to connect to the network. In addition, we don't have a relationship with the patient. Our relationship is with the providers who serve the patients.
While there are some variations on the model, the contracting structure is relatively straightforward. On the one hand we contract with vendors and physician systems, whether standalone eprescribing systems or more full-functionality EMR systems. So that those systems, when used by a properly authenticated physician, can communicate with pharmacies. On the other hand, we contract with pharmacies, either directly, with respect to those who have their own proprietary systems, or vendors who license pharmacy management systems to pharmacies. Today more than 95 percent of the nation's retail pharmacies have tested and certified on the network and physician software vendors whose customer base represents 150,000 prescribing physicians have contracted and are in the process of certifying. Accordingly pharmacies and physicians can communicate, in a real-time, secure, and HIPAA-compliant manner, prescription messages such as new prescriptions, refill requests, and refill authorizations.
All of these messages comply with the NCPDP scrip standard which was the standard adopted by the federal government for e-prescribing transactions in the Medicare Modernization Act. As you know the MMA has many other prescribing messages that have either been declared as foundation standards or which were evaluated in the 2006 MMA pilot programs, including messages for the delivery of medication history. The SureScripts network can handle all of these message types.
We're currently delivering messages in 49 states and the District of Columbia. The only reason that it's not 50 is because one state has yet to adopt laws that would clear the way for e-prescribing. In addition to the delivery of what I refer to as classic e-prescribing information, new prescriptions and refills from the physician to the pharmacist, we also make drug benefit coverage information from certain payors and PBMs available to physicians in a real-time and at the point of care. That way the most appropriate and costeffective therapy can be prescribed. In addition, in certain limited markets a patient's medication history, sourced from the pharmacy's dispensed medication history records or payor PBM records can be made available with patient consent to the provider who's providing care to that patient. Obviously a good example of a need for medication history was KatrinaHealth, which we and many others participated in.
There is an increasing demand in the marketplace for medication history information to be provided electronically to hospitals so that they can comply with their JCAHO medication reconciliation requirements. As you know JCAHO requires hospitals to conduct medication reconciliation upon admission and throughout the continuum of care. Today it's a timeconsuming, manual, and error-prone task. In addition, many personal health record companies are seeking connectivity to pharmacies so that they can pre-populate a patient's PHR with medication history in order to ease the burden on the patient from having to manually input all the prescriptions. We're evaluating business and legal issues related to connecting for medication reconciliation and PHRs. We're in discussion with many PHR companies. But to date we've not connected for purposes of delivering med reconciliation information or PHRs.
Any information provided through the Pharmacy Health Information Exchange can be used for one purpose and one purpose only, and that is the provision of healthcare to the patient. We have no right to use, and do not permit anyone who receives pharmacy information to use, it other than for the provision of care. Secondary uses are not allowed.
Given the sensitivity of prescription information and patient medication history information, every entity that sends, transmits, or stores any protected health information through the exchange, from the pharmacy to the prescriber and back again is either a covered entity as defined by HIPAA or subject to business associate agreements.
SureScripts is considered a business associate of the pharmacies as well as others and as such we've agreed to comply with all of the HIPAArelated requirements imposed upon business associates. We follow not only the HIPAA guidelines which as we all know are the minimum guidelines, but other best practices with respect to storage and transmission of PHI. That includes making sure that all transmissions are encrypted, use of redundancy and backup procedures, audit trails, intrusion technology, and secure encrypted databases in highly secure data facilities that require multiple levels of biometric identification to gain access. We have policies relating to employee conduct, limited use of PHI, retention and destruction of information, use of laptops, strong passwords. All the things that I'm sure are all familiar with, that we comply with HIPAA. We also do annual thirdparty audit tests to test our compliance.
Even though we believe our systems are obviously highly secure, in the unlikely event that there's ever a breach or PHI is mishandled, we have an emergency response team that's charged with responsibility for responding to any breach and taking appropriate steps to mitigate any harm, especially harm to those whose information may have been compromised. These policies include complying with any applicable state notification laws and working with our partners and covered entities to inform them and patients of a breach, as well as working with law enforcement, all as circumstances may require. We have a privacy officer, a security officer, and an internal committee dedicated to security procedures that's comprised not only of SureScripts personnel but the security personnel with the major pharmacy chains who provide information through the exchange.
We do have a standard HIPAA business associate agreement that we require all who provide or receive information to sign and comply with. Covered entities in fact sometimes request that we use their form of HIPAA agreement. Fortunately most of them do follow a common theme and have somewhat similar requirements. So I guess I would say is it a burden to manage various contracts? Yes. Would I prefer more uniformity? Yes. But for now it is a manageable contract process to ensure that we comply with all various agreements and policies.
We do all of this for many reasons. One, our owners expect it of us. Contracts impose these obligations to us. We adhere to a multitude of statutory and state common laws that govern privacy. And we publicly state, as so many others do about their own businesses, that we're HIPAA-compliant. But both we and our partners, those who use the Exchange, fully understand the public's trust that's necessary in order for the proper exchange of health information to occur. A breach of that trust would be devastating to us, not just because of legal liability issues but the harm to reputation and business would affect us, in our case the pharmacies, and also the deployment of health IT in general.
HIPAA obviously contemplated the electronic exchange of information. That's not new. I do believe, however, that a reasonable debate can and should occur as to whether when HIPAA was promulgated anyone could have seen the deployment of the health information exchanges as it is occurring today whether vertically-based by industry such as we are or regionally-based as such as the many RHIOs that are emerging. However, it not as easy as merely to say that a certain type of entity that now touches the NHIN, assuming we even know what that means, especially a non-provider, is now a covered entity. It's just more complicated than that, I believe. Even today HIPAA treats covered entities differently depending upon their nature and function. Accordingly, whether other entities should be considered covered entities and the requirements imposed upon them requires a balancing of the important privacy issues and the role and function of that entity.
We believe the focus should be on one, the security of information, two, the proper use of information, three, accountability for disclosures, and, four, vigorous enforcement of penalties against those who fail to properly secure or who misuse information. I think today, in today's world where enforcement is dependent on an increasing lengthy chain of various and perhaps inconsistent business associate agreements, trade agreements that are enforceable only to the parties to those agreements, may not create the trust in the system that's necessary. I will always use, address the use of data and security in our agreements and we would always vigorously pursue anyone who breaches those agreements. But I think one can legitimately question whether as a matter of public policy that's sufficient.
Having some entities covered by federal law and others not within the chain of custody does create some ambiguity and complexity in areas that I think should be devoid of ambiguity and complexity. Is the BA agreement required? If there are multiple BA agreements who has jurisdiction to enforce? Which state laws apply, even which federal laws apply. Clarity around these issues would be very helpful.
Some HIPAA provisions may not be relevant to health information exchanges such as ours, such as the requirement to provide a privacy notice to patients because we don't have that direct connection. There may be other requirements that should be imposed. Since today we as a company do comply with the privacy requirements of HIPAA's imposed on us by BA agreements, it would not be an undue burden if the requirements were imposed on us by HIPAA directly. But any additional requirements have to be rationally related to our function and services. The current debate is critical as we move from a paper-based system, and we appreciate being part of the system. Thank you.
>> Kirk Nahra:
Thank you, Paul. Why don't we hear from RxHub. Are you the only person?
>> Ken Majkowski:
Yes. Thank you my name is Ken Majkowski, I’m vice president of clinical affairs and product strategy for RxHub, and I’m a pharmacist by background. Next slide, please.
Just as a matter of overview, RxHub was founded in 2001 by three large PBMs, Caremark, Medco, and Express Scripts, specifically to create a national e-prescribing information exchange network. RxHub is open to all e-prescribing stakeholders to ensure the fastest route of widespread adoption and costeffective healthcare delivery. RxHub utilizes industry transactional standards to securely communicate consenting patient information in a real-time fashion between e-prescribing stakeholders. We provide the transaction of decision support information such as patient pharmacy eligibility, benefits, formulary, and medication history from more than 160 million patients to physicians at the point of the care. We deliver real-time information and electronic prescriptions to pharmacists in both the retail and the mail-order settings. RxHub does not perform functions covered under HIPAA, nor are we a business associate. Next slide, please.
From this schematic you can see that RxHub does not deal directly with patients either. We either are connected to certified payors and PBMs who supply us with demographic information so that we can locate a patient, and with RxHub-certified technology partners, point of care vendors, people who serve the acute care space, who can deliver this information to clinicians in a real-time fashion. The patients interact with clinics, pharmacies, and hospitals through providers and covered entities at that point. Next slide, please.
RxHub's infrastructure uses a master person index to identify where prescription benefit coverage exists when a person has presented for medical care. As part of the prescription writing process, the physician will reference a formulary and benefit database contained in the point of care system to prescribe a drug that is covered by the patient's pharmacy benefit and then write a prescription and allow that to be electronically transported and forwarded to the pharmacy. The MPI is a registry within RxHub's infrastructure that is loaded and maintained by the pharmacy benefit manager. The MPI data is drug benefit membership records that RxHub receives from the PBMs. A membership record includes basic person demographics that are used to match against demographic data that is contained in an eligibility request submitted by the point of care system at the physician's office, and includes an ID assigned to the PBM to uniquely identify this person's benefit that is stored in the system. This information is not shared by RxHub with the point of care systems, at least the unique ID. The formulary and benefit data is received by RxHub from pharmacy benefit managers and made available in file form to point of care vendors to download and include in their software.
Provider and pharmacy identification information includes basic physician and pharmacy demographic information and routing keys. Providers submit their demographic information to RxHub through their point of care system which is then downloaded by pharmacies and used by pharmacies to route refill and renewal requests to the point of care vendors. Likewise, pharmacies submit their demographic information through their pharmacy systems, which is then downloadable by physician systems and can be used by physicians to route new script requests. Transaction requests and responses for eligibility, medication history, new scripts, prescription refills and renewals are routed between prescribers and PBMs and pharmacies. Next slide, please.
If we look at the actual routing, what we route are formulary and benefits from payors to point of care vendors, eligibility requests from point of care vendors and pharmacies to the payor, and then the eligibility response from the payor to the point of care system or pharmacy. Drug histories are requested by point of care systems and hospital systems. Drug history responses are then routed back from the point of care, from the payor to the point of care system. New prescriptions are routed to pharmacies and renewal requests are routed from pharmacies to prescribers. Next slide, please.
In all cases we use open standards. For the eligibility request we use the ANSI X12 270-271, which is the eligibility standard to find in the HIPAA transaction code set. We follow NCPDP version 8.1 for script and formulary, or script and medication history, excuse me, and NCPDP version 1 formulary and benefit information transaction. And for medication history in the acute care setting we use HL7 version 2.3 ADT transactions, ORU, and RDS transactions. The methods of delivery of this information is via VPN abd private connections to the payors and SSL-encrypted connections to point of care systems and to pharmacies. Next slide please.
RxHub protects the information in two basic ways: through business operations and through technical infrastructure. In business operations we have contractual obligations with all of our participants that address intellectual property, data use, security and privacy, and HIPAA, and the participants are required to follow all federal, state, and local applicable law. We have an annual HIPAA security audit from an external firm as well as annual HIPAA training for all employees, again from an external firm. We have just received our EHNAC review and accreditation, and I'll mention that in a second. We have staff confidentiality agreements and a formal incident response plan for privacy and security breaches.
On the technical infrastructure side, we have private secured and encrypted networks. Strong user name and password. Local access restrictions. Intrusion detection. We follow NCPDP and ANSI standards. We have a tier-1 data center with facility access control. Backup media encryption. Security, privacy, and data retention policies. Separate access points for production network versus our development or QA network. And data access logging. Next slide, please.
EHNAC is the Electronic Health Network Accreditation Commission and they indicate that a VAN or a clearinghouse has met or exceeded EHNAC's performance criteria for EDI, a combination of speed, accuracy, and data integrity. EHNAC accreditation is based on independent peer evaluation of the entity's ability to perform at levels based on industry-established criteria. The focus of the accreditation is on transmission timeliness for e-prescribing, timeliness of process, transaction processing, compliance with industry standards, and privacy and security for new prescriptions and renewals. EHNAC has accredited up to, I think at this point, 30 companies who have improved their efficiency and quality of service through objective and thorough business evaluation, heightened awareness of best practices and changes in the electronic marketplace, and formalized business discipline, organization, and planning through assessment of business performance against measurable industry criteria. Of the transactional companies that EHNAC has certified include companies like Emdeon and GE Healthcare, McKesson, Siemens Medical Solutions, MedAvant, and others. Next slide, please.
We communicate with our participants through several ways. Contractually, because we contractually bind them through some of the things I mentioned earlier as it relates to security and privacy and intellectual property and data use, through technical presentations during the implementation and contracting process, VR implementation guides, via monthly participant status calls that all participants are invited to, through work groups and through symposiums. Next slide, please.
RxHub does not communicate directly with patients or consumers. Patient control is executed at the physician office and subscriber control is executed through their benefit enrollment. Patients at those two levels have the ability to grant consent for transfer of information. Point of care vendors are contractually obligated to follow and enforce user compliance to all applicable law. Drug data sources are required to confirm the status of the consent flags that are in the transactions during the transactional request. Next slide.
While RxHub is not directly regulated by HIPAA, because we are not a covered entity or business associate, we are obligated to conform to the HIPAA privacy and security standards and with state laws governing e-prescribing. Compliance with HIPAA privacy and security is the norm for covered entities in the e-prescribing industry and we contractually obligate ourselves to conform with these requirements. Next slide.
We view HIPAA as the special standard for e-prescribing. Again, since we are not a covered entity or business associate and all of our partners are, we need to meet or exceed the privacy and security standards established by HIPAA. Our recent EHNAC accreditation validates that we are in fact operating in conformance with these established requirements. Next slide.
RxHub follows HIPAA privacy and security standards because we need to be able to meet our customer's business privacy and security requirements. You asked about the business implications. If we didn't do this, we wouldn't have a business. There would be no business for us to be in, because our participants have to follow these and they require that of us in order for us to be in business. The implication for following HIPAA standards is a total business requirement for HIPAA.
I've included at the back as an amendment some of our privacy and security policy summaries, and they're there just for your reference. I thank you very much for the opportunity to present this information today. Thank you.
>> Kirk Nahra:
Ken, let me just ask you one quick question before we go on to the next presenter. You said you're not a covered entity, you're not a business associate. Is that because you're a subcontractor to business associates or your position is you're not
>> Ken Majkowski:
Our position is that we're not a business associate. We don't perform any functions other than to serve as the electronic network to transfer data between business associates or covered entities.
>> Kirk Nahra:
Thank you. Why don't we turn to our next presenters. From Massachusetts?
>> Alan Harvey:
I'm Al Harvey vice chair of the Massachusetts eHealth Collaborative, and a physician. And on the phone we have, let's see, Micky Tripathi. Micky?
>> Micky Tripathi:
Yes.
>> Alan Harvey:
Who is our chief executive officer of the Mass eHealth Collaborative and Steve Bernstein, who is our general counsel and a partner at McDermott, Will & Emery. So let me coordinate.
>> Kirk Nahra:
Are the two gentleman that Al mentioned on the phone?
>>
Are they muted?
>> Kirk Nahra:
Do you need them?
>>
Can you hear us?
>> Alan Harvey:
Micky is our CEO and will be presenting.
>> Kirk Nahra:
Can any of the Workgroup members on the phone just let me know if their line is still connected.
>> Micky Tripathi:
Should I begin?
>>
Technically do you want to go on and we will come back?
>> Kirk Nahra:
I think the whole phone line has been disconnected. That's why I want to I thought maybe just those folks were not
>>
Why don't we hang up?
[laughter]
>>
Are there still other people on the phone?
>> Alison Rein:
This is Alison. I'm on the phone.
>> Jennifer Macellaro:
It looks like they lost the line in the room and they are going to be dialing back in.
>>
Just wanted to make sure we didn't do something.
>>
Yes.
>> Micky Tripathi:
Hello, hi, this is Micky Tripathi.
>> Steve Posnack:
This is the AHIC meeting. We have technical difficulties and we will get you back up.
>>
All right. Thank you.
>> Steve Posnack:
Here we go.
>> Kirk Nahra:
Are people on the phone at this point?
>>
Yes.
>> Kirk Nahra:
Any of the Workgroup members, could you let me know if you are hearing this?
>> Alison Rein:
This is Alison.
>> Kirk Nahra:
Do we know if the line is dead or
>>
From Mass eHealth Collaborative.
>>
We are hearing Micky.
>> Kirk Nahra:
Why don't we take a break for five minutes?
>>
Yes.
>> Kirk Nahra:
Let's try to be back. I'm sorry?
>>
I said we can hear Micky.
>> Kirk Nahra:
We are going to take a break for five minutes. But let's try to be quick. Let's really do that in five minutes.
>> Micky Tripathi:
Hello? Who is on the phone?
>> Gina Perez:
This is Gina Perez, from Delaware.
>> Micky Tripathi:
Hello, Gina, this is Micky Tripathi.
>> Peter Basch:
Peter Basch, MedStar Health.
>> Jennifer Macellaro:
Everyone on the phone, if you can just hold on a minute, they are going to be taking a break until they figure out what's wrong with their phone.
>>
We couldn't figure out from our end, because we can hear everything.
>>
We could run the meeting from here.
[laughter]
>>
Meeting adjourned, problem solved. I'm going to go on mute.
>>
Don't say that to people that just put all these presentations together.
>>
Oops, oops. Okay I'm going to go on mute.
>>
You guys have information from all these panel 2 people?
>>
Pardon?
>>
Do you have the presentations for the panel 2?
>>
We had the, I had the presentations for everything but the one just given. We have got both Massachusetts. And we have the WebMD. And we have the Rhode Island presentation.
>>
The RxHub one is actually one of the only ones on the AHIC Website.
>> Gina Perez:
And I didn't submit one for Delaware because we were limited on time.
>>
We will take good notes.
>> Gina Perez:
I think I'm supposed to submit something in writing afterwards.
>>
That sounds good.
>>
So then we won't take good notes.
[laughter]
>> Dan Rode:
This is Dan Rode. I'm going to go on mute for a few minutes, too.
>> Micky Tripathi:
Is Gina still on?
>> Gina Perez:
Yes, I am.
>> Micky Tripathi:
Hey, Gina, it is Micky.
>> Gina Perez:
Hi.
>> Micky Tripathi:
Hi.
>> Gina Perez:
How are you doing?
>> Micky Tripathi:
Good. Congratulations on your announcement. That was great.
>> Gina Perez:
Yes. Well, somewhat premature. We are still bringing it up, but we do have data moving in production so
>> Micky Tripathi:
I read between the lines and understood. But still, it is still great.
>> Gina Perez:
I was trying to be vague.
[laughter]
>> Micky Tripathi:
Well, I think it is great.
>> Gina Perez:
Thank you. Yes, it is pretty exciting. We are, as you know, this has been going on for a really long time in Delaware. We are pretty excited to be where we are.
>> Micky Tripathi:
This is Medicity, right?
>> Gina Perez:
Yes.
>> Micky Tripathi:
Very cool.
>> Gina Perez:
We are doing a heck of a job. How are you guys doing?
>> Micky Tripathi:
We are doing well. All the operational stuff is, you know, it is operational stuff. But we hope to have the first of the three health information exchanges well, you know, in some ways they are already up and running, in a way that you will appreciate, I think. In two communities we already have communitywide lab result and radiology report delivery into, right into EMRs already. That's already happening in Newburyport and North Adams, and has been happening for months now.
>> Gina Perez:
Right.
>> Micky Tripathi:
So in some ways our health information exchange is up and running. I mean, that is what health information exchange is for a number of places.
>> Jennifer Macellaro:
Can I just interject real quickly? This is Jennifer. They are going to be taking a break. In the meantime, we are still being broadcast, so if everybody wants to just hold on or, if they want to be aware the public can listen to their conversations, that's fine, too.
>> Micky Tripathi:
Okay.
>> Jennifer Macellaro:
Okay.
>> Gina Perez:
Thank you.
>> Micky Tripathi:
All right. We will catch up later, Gina.
>> Gina Perez:
Okay.
[break]
>> Vernette Roberts:
Jennifer?
>> Jennifer Macellaro:
Yes.
>> Vernette Roberts:
Okay. We are back on. Do you have a break sign up on the screen?
>> Jennifer Macellaro:
Yes, I do.
>> Vernette Roberts:
Okay. They’re going to come back probably in about five minutes or so. So I’ll let everybody know we’re back live, because they were calling the two speakers out, and nobody could hear us, that’s how we knew it was a problem.
>> Jennifer Macellaro:
So we’re waiting five more minutes?
>> Vernette Roberts:
Yeah, and we’ll be ready for Micky and Steven Bernstein, I believe, if you can make sure they’re still on the phone. I’m going to hang up and go do the mics.
>> Micky Tripathi:
We are on. Can you hear us?
>> Vernette Roberts:
Okay, great. Yes, we can hear you now, but we lost the connection for a minute. We’ll be going back -- we’re on break right now. Okay. All right.
>> Kirk Nahra:
Can we go ahead and take our seats please?
>> Vernette Roberts:
Jennifer?
>> Jennifer Macellaro:
Yes? Yes?
>> Vernette Roberts:
We’re about to go back, as soon as everyone takes their seats.
>> Jennifer Macellaro:
Okay.
>> Kirk Nahra:
Why don’t we go ahead and get started again, everybody, if you could sit down please?
>> Vernette Roberts:
Thank you, everyone, on the phone for your patience.
>> Kirk Nahra:
We are back online. Can someone from the Workgroup acknowledge they are hearing me so that we can acknowledge we are back online?
>> Peter Basch:
We can hear you just fine.
>> Kirk Nahra:
Peter, how long have you guys been off?
>> Peter Basch:
We were never off.
>> Kirk Nahra:
You were never off.
>> Peter Basch:
When you hung up - I shouldn't say hung up on us. When you disconnected the line, we could hear the whole conversation when you were saying you could not hear things
>> Kirk Nahra:
You were just, you guys were just muted and could not respond?
>> Peter Basch:
We did unmute and try to respond. I don't think you heard us.
>> Kirk Nahra:
It was not getting back to us. Good. So we did not in fact, Ken’s off the hook for having to repeat his session. Good.
>> Peter Basch:
No, we heard all the nice comments you made about us on the phone as well.
>> Kirk Nahra:
Excellent. Excellent. Well, we did a couple after we disconnected. So I apologize for those. But why don't we return back to where we were? And Alan if you could start over and reintroduce your folks and then we can get them on board.
>> Alan Harvey:
Micky and Steve are you on?
>>
Yes, we are here.
>> Alan Harvey:
Excellent, great. As I mentioned, I'm Al Harvey. I'm a physician and vicechair of the board for the Mass eHealth Collaborative and presenting will be Micky Tripathi, our CEO of the Massachusetts eHealth Collaborative, and Steve Bernstein our general counsel and a partner at McDermott, Will & Emery. All set, Micky?
>> Micky Tripathi:
Yes, thanks. I assume we cannot see the slides over the Web, so I assume someone there driving the slides?
>> Kirk Nahra:
If you could let us know when you need to advance them.
>> Micky Tripathi:
Okay, great. So I assume that the cover slide is on now. So if you could you advance to slide one, please. Some of these are animated so I will just say next slide, which would mean click it. That doesn't mean the whole slide will advance. Just by way of quick background introduction to the eHealth Collaborative. There were two sort of important threads to the launching of the eHealth Collaborative. One is, and I'll start at the bottom here, of slide 1, is a 50 million dollar financial commitment from Blue Cross/Blue Shield of Massachusetts to doing something about using health IT to improve healthcare delivery. It was really sort of a visionary approach from Blue Cross to say let's make a large investmentin funding something that will change the terms of sort of the conversation about how to improve healthcare delivery or take it to the next level in Massachusetts. The second important thread of the eHealth Collaborative is the role played by the Massachusetts chapter of the American College of Physicians which had this is a couple of years now had taken their top priority pushing for universal adoption of electronic health records in Massachusetts.
So the eHealth Collaborative, and if you could click the next slide, please, is really the coming together of those two sort of streams of thought that led to the bringing together of 34 leading healthcare stakeholders in Massachusetts to launch the company. We were launched in September 2004. We are a notforprofit registered in Massachusetts. And as I said, we are backed by 34 leading Massachusetts organizations.
Next slide, please. Slide two here, there is 33 organizations listed in the title. There is one nonvoting member which is the regional CMS office, but not that we need to go through every one of these organizations. But just a couple of things to point out. One, we deliberately tried to get representation from every part of the healthcare delivery value chain in Massachusetts. So you see here representation from large institutional providers, from health plans, from purchasers, as well as consumers and public interest organizations to the extent that we could reach out and get that representation. The second thing I would like to point out on this slide is that within each of those healthcare delivery value chain elements we wanted to make sure that all the players, the major players, were there, including the biggest competitors. So for example, under health plans you will see Blue Cross/Blue Shield is there, but so is Fallon, so is Harvard Pilgrim, so is Tufts. All one organization, one vote. We are, even though our financial commitment is from Blue Cross, we are a separate company, guided by this board.
Next slide, please. So the eHealth Collaborative launched a set of pilot projects where we invited any community in Massachusetts to apply to be one of three pilot projects where we would essentially, to put it in lay terms, wire healthcare delivery in three communities as a way of demonstrating the costs and the benefits and the barriers to adoption and hopefully organizational ways of overcoming those barriers to adoption, again, with an eye towards statewide, ubiquitous adoption of electronic health records. We got 35 responses to our request for applications. That's represented by those red dots there on slide 3. And we chose three communities to be our pilot projects. Brockton, which is sort of the bottom star, the top right star is Newburyport, up on the north shore, and North Adams is in the top left corner there, all the way over near New York State. All together that constitutes about 500 physicians who are, practice in about 160 practices. And it's about, you know, 220 practice locations.
So next slide, please. What are we doing in those practice locations? I like to bucket it into four main activities. If you start at the bottom yellow box there on slide four, is clinical IT implementation support. So for each of those 200 practice locations, we are purchasing and installing EMR, integrated electronic medical record and practice management systems with all the hardware, the software, the preimplementation site assessments, and the post-implementation training involved with that in all of these 200 or so practice locations. The second piece, that I think will be more of the topic of this session, is the connectivity piece which is health information exchange. In each of the three communities we will be connecting up those practice locations for the creation of a health information exchange that will allow the exchange of patient-identified information for treatment purposes in each of those communities. And then we have an evaluation program. I won't spend a lot of time on that unless there are questions there. Finally we have a management and coordinations piece, which is really about governance. And, again, I won't spend a lot of time on it, but that governance, in each of the three communities there's a steering committee of the leading stakeholder organizations in each of the communities that has become a very important, sort of almost policy-setter for the way we are handling privacy, security issues in each of the three communities and how we are, you know, representing to patients what it is we are doing in each of the three communities. I'm happy to come back to that a little bit later.
The next slide, please. Our timeline is, we are through the physician recruitment stage .We started in mid-2005 with physician recruitment, ended that in early 2006. We had 96 percent participation among the physicians we asked. We got very high participation. EHR implementations are extending, the vast majority will be done in end of June 2007. So right now we have roughly 70, 75 percent of all of those 500 physicians up and running on their electronic medical records, the standalone electronic medical records. And then health information exchange implementation has started in late 2006. And by the end of June, 2006, we 2007, I'm sorry, we expect to get in each of the three communities to have the health information exchange up and running. I will describe in detail what that means because that's important to our conversation about privacy aspects in a second. But just to give you an overall timeline. The pilot project itself ends in the end of June, 2008, at which time we will essentially transfer these, all of the infrastructure that we have built in these three communities will transfer that to each of the communities for them to operate, own and operate into the future.
Next slide, please. So in talking about health information exchange, which will be the basis for our conversation about the privacy and security aspects of it, you know, the goal is to and many of you probably seen slides like this. But the goal is to bring together information to improve patient care from a current state situation that has a couple of aspects, I would say. One really three maybe to point out here -- one is that all of these nodes, all of these entities around that circle there, from physicians to ambulatory centers, aren’t electronic right now. Some are, some aren’t. So from our perspective it is about, first, making sure they are electronic with a focus on the ambulatory care setting. Second, you will notice by that over-exaggerated set of arrows there, connecting them up is arduous, redundant, and incredibly efficient right now, with each of those lines representing a point-to-point interface that can cost anywhere from 15,000 dollars to 50,000 dollars. There's a considerable expense there, not to mention all the wasted effort in doing things that are redundant. The third thing I would like to point out about the current system, is you will see I have the patients removed to the bottom right, where patients really are not a part of that conversation. You know, most of what we are talking about there is all B-to-B, in CIO terms. It is all business-to-business stuff where patients have, any type of window, they have a very limited, if any, window into that.
Next slide, please. What we would like to do is get to a future state where everyone is electronic, that has a more, sort of rational, efficient basis for the exchange of information that is not only about efficiency but is about having a set of ground rules that are transparent and enforceable and there for everyone to see. And I think we will bring a whole lot of consistency to what is an inconsistent process right now. And then finally brings patients into and indeed, hopefully, puts patients at the center of it in certain ways.
Next slide, please. So let me talk in detail about what we are doing in North Adams, just in two slides, just so you know what we mean by health information exchange and then I will turn it over to Steven Bernstein to talk a little bit about the privacy policy aspect of this.
So if you could click the first slide, please. There are a few dimensions that I want to make sure you understand about what it is we are doing. The health information exchange will constitute a set of different pieces. The first area is referrals management where, if you click that, it is basically a point-to-point way of, over a network, essentially sending a secure email for the purpose of referrals. And as Steven will describe in a second, I mean, that happens right now in a, you know, referral treatment relationship. But right now it happens over the phone, fax, regular U.S. post office mail. And what the health information exchange will do is just allow another vehicle for what is the type of transaction that happens every single day right now, but it will make it easier and trackable.
If you could click the slide again, please. The second piece is around patient recruitment. Because as Steve will describe we are, we have gone with an opt-in policy with respect to data that is put into the data repository that I will describe in a second. And what that means is that no data will be taken from any of the EMRs for population in the, sort of the community medical record without getting explicit patient permission first. So there is a big patient recruitment effort. That little picture there is just the recruitment brochure we have for North Adams we have sent out to, we printed off 20, 30,000 copies and sent them all around North Adams, as a part of the consent process and education process for patients.
If you click the slide again, please. So the health data exchange is that health summary, and I will describe it in greater detail in a second. But it's essentially a clinical repository of an agreed upon set of information that will be held at the center in a patient-centric view. So it will be provided, essentially pushed to the center, by each of the deployed systems in the ambulatory setting as well as the hospital, and then merged and then essentially transposed into a patient-centric rather than a provider-centric view at the center. And then finally, the last piece of the patient portal, which we hope to launch in each of the two communities, Newburyport and North Adams for sure, hopefully by the end of the calendar year, depending on how quickly we can get the clinical piece of this up and running. Our view of the patient portal is perhaps a little bit different than other views out there, and there are many, many views of that. Our view is that the patient portal ought to be a view on to a clinical infrastructure. So that you create the clinical, you create the exchange for the benefit of treatment among clinicians and then the patient portal is a view onto that same infrastructure that you have created. It is not a separate infrastructure.
So if you would click the slide please, to slide 8. I will just describe in a little bit more detail what this health information summary is because that's really the basis of the privacy issues that we have here. Slide 8, as you see on the lefthand panel there, basically the summary is taking data out of each of the individual EMRs, from the individual physician offices and then putting it together. Merging it into a consolidated clinical abstract, which is a patient-centric view.
If you could click the slide once, please. What we have done, though, is we have, out of the EMRs, we have said and we have represented to patients and we have decided at the community level that everything does not go from the EMR. Only certain things will go to the EMR that strike the balance between being clinically useful and, but not disclosing too much information that patients would find, you know, genuinely private. Some of that is a legal definition of what might be private or sensitive. And then frankly some of it is more about, what are patients going to be comfortable with, and clinically useful. So what we did as depicted here, there are certain things we decided will only reside in the individual physician's office record. And those are private office notes, meaning the detailed sort of text blob kind of notes, consult letters, anything that's scanned, and certain non-consented items that will reside at the physician office level.
If you can click the slide again, please. But at the center, which is the eHealth summary, as we call it, will have a set of data elements that are structured data and that sort of constitute what we think of as vital information. Information that is clinically useful, and that we think that most patients would find acceptable in terms of being something that they would like to make sure that any provider of the network has that to get a more complete picture of them for treatment purposes. So you know, we have agreed to the medication list; problem list; procedures; certain elements of social history, really mostly around smoking status; allergies; some past medical history, again, to the extent that it’s codified; certain elements of family history, again, only those that are codified, like history of cancer in the family, for example; lab results; certainly radiology results; and immunizations. That core set of vital information that's passed and shared at the center.
So let me now turn to, if you could click the slide to slide 9, and then I will ask Steve Bernstein to walk us through our privacy approach for that.
>> Steve Bernstein:
Right. Really quickly here, I think one of the points that Micky made which was key, is the involvement of the communities and the community steering committees. And there's a privacy and security work group in each one of the communities. That's who we have been working with probably for the better part of a year and a half, to really sort out the opt-in approach, what really is the consent about. And one of the key decisions was to make the decision to require an opt-in, meaning the information is only moving into this repository that Micky mentioned based on patient consent.
And fortunately, in Massachusetts, we were effectively, in our view, required to do that anyway because Massachusetts privacy law is more stringent, more protective, than is HIPAA. So the usual HIPAA standard of TPO consent or no consent for TPO, that didn't really work for Massachusetts. So we had a leg up in that sense, although some people might say that was frustrating, but that's where we ended up.
And then on top of that in Massachusetts, there are specific, some specific statutes, HIV for example, where there is an each-time consent. Meaning every HIV test result, before it moves there is another consent. So we really have a double layer consent process where there is this education with the patients, through brochures and other things about what they are consenting to, and I'll talk about that in a minute. In addition, when you get down to the sensitive information there will be another layer of consent that the physicians and the patient have to have a second kind of interaction before that information will move to the center. And if that interaction does not occur, it does not move.
I think what we also have sort of configured is that right now these point-to-point exchanges and information, where you are dealing with a specific episode of care where a physician has to make a referral for a particular event or an MRI or a type of test, there is often dialog with the patient right now. And we are viewing that as a continuing process which we want to improve and make sure that physicians continue to have that dialog. But for the point-to-point exchange, as compared to the general structured data that will be in the center, those kind of consents will occur mostly, principally verbally between doctor and patient, meaning patient, I'm going to refer you to X. Patient says fine. And in order to get that process going, I'm going to engage in a point-to-point exchange through the secure messaging to get that information out.
Next slide. So I think the important thing to think about for privacy, from our perspective, what we looked at was, this structured data at the center, where we have this summary, is really a new kind of endeavor, I think. And that's really where our focus of our consent lies. So that when a patient looks at the consent, which we have spent a ton of time on, and the communities are all slightly different about how they’ve articulated that, it is really about this multiple pulling of data into a structured data set, that's what they are consenting. We have had to make clear, through lots of different educational points, who is going to access it, so it is the physicians and participants in that community, what's available -- it actually says any data, but it is really just certain data. It is limited amounts of data that Micky described a few slides back, and when is it made available. And that's the key, it is really available at any time. These are not systems that are sort of dependent on whether a node, a physician node, is actually up and running. It is available all the time, and that, we felt, was really important. And the hospitals will play into this exchange as well. Right now the project has been focused mostly on the ambulatory EMRs, but the physicians will participate in the overall exchange. And there will be an initial movement of data from the hospitals into the structured patient summary in the middle, because they already have electronic data. And so we are working through processes to get that consent, to move that data so that, day one, when a patient ends up at a physician's office, there actually will be data in that structured summary, even though the patient hasn’t been to a physician. If they have been to one of the participating hospitals that data will be in there. I think I will turn it back to you, Micky.
>> Micky Tripathi:
I think we just have a couple of slides left. One I wanted to describe to you in detail, so what is the opt-in policy that we have, and if you could click the slide to slide 11, please.
We came down to what we call an entity-by-entity opt-in, meaning that we would get the opt-in or the patient consent or permission for each legal entity that the patient has a relationship with. That's as opposed to sort of a global-type consent which -- and I should actually specify, in North Adams, it is a global consent for a variety of reasons, but mostly because that community is so small and tight, that the physicians themselves were, you know, sort of came together and agreed that they would allow essentially every other physician to do their consents on their behalf. When you couple that with the fact that the community is small and you could get, list all the practices on one consent form so that the patients had, we were confident they would have an understanding of what they were signing, then we decided that global consent, you know, made sense there. We are, right now the early results in the opt-in are that we are getting 96 percent roughly positively opt-in in North Adams. So so far it is, it looks like patients are feeling comfortable with it.
In Brockton and Newburyport we have this model, which I will describe on slide 11 here, which is the entity-by-entity opt-in. If we just walk through this for a second, I think it will be pretty selfexplanatory. So on the lefthand side we have sort of our putative patient, Jane Jones, who has relationships with a number of different providers, some of themambulatory, some of them inpatient.
If you could click it for a second. Just click the slide for a second. Number one, is that the patient visits the clinical entity for care and is provided the option at the first visit, after we launch the health information exchange, or after we launch the opt-in process, which begins before the health information exchange. They will have an opportunity, at each legal entity, to opt-in.
Then if you click the slide, please, for the box, which is number 2 there. The patient will then have the opportunity to choose which entity's records to make available to the network. So he or she might say -- well, in this case it is a she. It’s Jane Jones might say yes to my primary care physician, yes to my endocrinologist, yes to the hospital, no to the psychiatrist, for example.
Then if you click the slide again, please. Then the consented patient information will then be published to a repository at the center. But notice that none of the information that is held by the legal entity for which she didn't consent, none of that information will be pushed to the center. And indeed, there won't even be at the center any indication that there are any other records out there, which was a long conversation that we had about how that, in and of itself, was disclosing. So in terms of the repository view, any other records are invisible to the system, in that sense, because that gives patients the full control over what they would like exposed.
If you click it again, please, to box number 4. Then the physician or physician office will be able to view the data prior to or during the patient visit when Jane Jones then visits any individual provider who is going to access the system. I will point out that, you could just as easily say that that would be a patient portal having some type of view onto that integrated repository as well, if the patient him or herself wants to log in and get that kind of information. So that's just sort of a high level schematic of how the opt-in works.
If you click the slide, please, to slide 12. This is the last slide. I just wanted to give a perspective, on if we step back for a minute, how do we see this rolling out across the state of Massachusetts. We kind of think of this network, the health information exchange being sort of the same network of networks idea that is sort of the model for the, sort of the national, the national model with, you know, we kind of think of it as the grid in the last mile.
If you push the first push the slide, please. The eHealth Collaborative and each of those dots on the Massachusetts map there represents one of the communities who would apply to be a part of the Collaborative. The eHealth Collaborative is really sort of focused on that last mile which is, how do I get an electronic system into the hands of every provider, and how do I connect them up locally into a health information exchange that makes sense, on a market basis for a medical care market or a medical referral market.
And then if you push the slide again, please. Then there is the grid component which is the intercommunity connectivity which is MA-Share, which is sort of a sister organization of the eHealth Collaborative, which is sort of our statewide virtual RHIO, as it were, whereas the eHealth Collaborative is in effect feeding local RHIOs, however you want to define that hierarchy. But the idea being that there is a thin amount of data and a set of standards about that thinner amount of data that could be passed statewide, in a regional or statewide type network. You know, with an eye toward interoperability, not only of the systems, but of policies at a higher level. And so we are working together with MA-Share to try to define what that common denominator is as we sort of move through this. So that's all we have in the way of formal presentation and look forward to your questions and to conversation.
>> Kirk Nahra:
Okay. Great. Thank you very much. We are going to make one switch in the agenda now. Amy, if I could ask you to hold off. One of the folks on the phone, I know, has a short timeframe. And so I wonder, Gina, could I turn to Gina Perez from Delaware?
>> Gina Perez:
Yes. I'm here. I wanted to let you know I've cleared until a little before 4:00 so I have a little additional time.
>> Kirk Nahra:
Well, why don't we have got you on board. Why don't you go ahead and do your presentation.
>> Gina Perez:
Okay. Very good.
>> Kirk Nahra:
Thank you.
>> Gina Perez:
This is Gina Perez. I'm with the Delaware Health Information Network. And I apologize for not being there inperson. We have a very busy time right now. We are in the middle of our system implementation.
So to give you a little background, the Delaware Health Information Network is also known as DHIN. It is a public/private partnership that includes the, for the exchange of clinical health information throughout the State of Delaware. It is a collaboration of physicians, hospitals, commercial laboratories, community organizations, and patients to provide for the secure, fast, and reliable exchange of health information among medical providers in the state.
DHIN provides one source and one format for all clinical results. And we see that as a tremendous success and benefit for our physicians. The primary goal of DHIN is to provide, it is basically to improve patient care. That is the reason DHIN has always existed and the reason it will always exist.
In the current phase system implementation, DHIN is delivering results to the ordering physician and anyone the ordering physician copies on the order. The results available through DHIN include laboratory tests; pathology tests; radiology reports; admission, discharge, and transfer reports; and face sheets, which include patient demographics and payer information. Results are sent to DHIN from three hospital systems, in five locations, representing the entire state, as well as LabCorp. Additional providers are expected to be added to the system within the year. These will include additional hospitals, additional laboratories, and radiology providers. During the pilot phase we have 28 practice sites and 64 physician users.
DHIN provides three ways in which a physician may access clinical information. The first is through a clinical inbox which provides a secure mailbox, which results are sent to the physician. Results may be sorted by patient, by type of result, by outofrange alert, by the sending organization. It is a central view of all results for that practice, or that individual physician, depending on how the setup is created for that office. So a physician can go in and see a list of all of the results for his or her patients. He can, or she can, determine where that result was sent from and who it is for and whether it is an outofrange result that needs to be addressed immediately.
The second way of delivering results is through an interface to an electronic medical record system. For those physicians who have EMRs, they determine how that information comes into their EMR system and how it is dispositioned.
For the paper practices, we have an auto-fax or auto-print option, and that's where the results are received directly to a fax or printer. Probably the same way that physicians getting those results today. But it is through one source, through the DHIN, and it's in that single format that is the DHIN format. Results are available from anywhere there is highspeed Internet connection using a secure DHIN login.
We protect information through 128bit SSL encryption. We have robust security and access controls, including the individual user IDs with strong password requirements. The system and data center is very robust with security protocols, including multiple DMVs withinthe network, lockdown ports, masked IPs. Traffic in and out of the network is monitored and involves intrusion detection and protection.
Additionally DHIN is complete[inaudible] which includes many reports where we can monitor usage and investigate and address anomalies. Regarding HIPAA, DHIN is not considered a covered entity. We’ve taken the approach of being fully HIPAA-compliant. All participants of DHIN are regulated by HIPAA, so we have business associate agreements with each of them. We want users and consumers, so physicians and consumers to feel confident that the information is being protected and monitored and is solely being used for clinical use and treatment, for patient care.
DHIN's current purpose and phase is a business-to-business model. We are moving, probably early next year, into Phase 2 implementation which is a record locator system. It will provide a patientcentric view of a patient's history to an authorized provider, that is one who has an existing relationship with a patient or who establishes a relationship using various requirements that will include having to give a reason for use of that information. We have a consumer advisory committee whose role it is to develop privacy protocols and to guide in the development of consumer education materials, and that is critically important as we move toward the record locator system approach. And that's all I have.
>> Kirk Nahra:
Okay. Thank you very much. Amy, appreciate your patience. Why don't you go ahead now?
>> Amy Zimmerman:
Well, thank you. It is a pleasure to be here and to continue to share around providing a slightly different, well, not model for health information exchange, we are not quite as far ahead as Massachusetts, even though we are just down 95. We're jealous of some of where they've gotten so quickly. We don't have as robust EMR adoption as they have, and our model is a bit different than Delaware’s. What I want to do is just give you a little background in terms of what we are attempting to do and then really talk a little bit about the framework and how we have been going about trying to deal with the confidentiality and privacy areas. Next slide, please.
So just to gave you a general sense in Rhode Island, we are about 1 million people. We really do have a statewide healthcare market. We're trying to build a health information exchange on a statewide basis. We have two large integrated delivery networks that probably have slightly over 50 percent of our hospitals, and then many small provider organizations. We also have an existing collaborative healthcare quality organization. Many of you might know Laura Adams and the Rhode Island Quality Institute. They were in existence in 2002. Much like Micky was talking about the board of the Mass eHealth Collaborative, it is really the senior leaders of the healthcare industry in Rhode Island and all on the value chain that are board members of that organization. And we are really approaching this as a public/private partnership, and I will come back to that in a minute. And also our Governor is very behind this. He has a fivepoint healthcare agenda, and the health information exchange which he refers to as anytime, anywhere healthcare is on that five point agenda. Next slide, please.
So our statewide health information exchange is a little bit different in that really it is the Department of Health that received some initial funding through AHRQ at the behest of the community to start to build the health information exchange. But the governance is all done through the Rhode Island Quality Institute, which again is a communitybased, notforprofit organization. With the intent always to have the health information exchange, once we get some initial functionality up and running, to really move back into the community and have the management and operations be transitioned to a RHIO. Interestingly, we can come back to this later, last summer legislation was passed that required the State to designate the RHIO through an open bid process in order to have the RHIO be eligible for State funding. And that would have to be matched by additional private funding primarily from insurers. So this really, you know, again, it is a lot of working between government and the public, the private sector, and that's presented some interesting challenges.
Our initial scope is really to create a statewide master patient index, and then start sharing laboratory results and medication history information. More on a lookup and retrieve basis, some of the functionality around results delivery and the referral messaging is not initially constituted in our initial pilot project. We have four initial data sharing or data submitting partners, including our largest integrated delivery network system, our public health laboratory at the department of health, a local chain, a local laboratory that has a large market share, and then SureScripts we’ll be working with to supply the medication history initially. And certainly we have many ideas on future capabilities that we want the health information exchange to have, including adding additional data types, data users, EMR interfaces, a patient portal much like Micky described so I'm not going to get more into that. Next slide, please.
Principles for getting started. We really have taken the approach that it is important to build incrementally, to really provide some initial value and gain trust before expanding on. This played out in several discussions, specifically around uses of data. We circled a lot in conversations through some of our work groups. And we finally, in order to get people to feel comfortable enough to let us start down this road, we had to limit the use of health information exchange for clinical purposes and the coordination of care. Knowing that there is a lot of value down the road in secondary uses appropriately controlled, de-identified, in an aggregate. But we had to put that constraint on or it was just making the community way too anxious to think about that.
We also really intentionally tried to seek and bring in individuals from diverse and multiple perspectives. Although this takes a lot longer in -- and I think Micky can probably attest to this -- in trying to establish policies and approaches and frameworks, we do believe that once we have those identified we will be able to implement quicker because we will have better buy-in and certainly better adoption at the end. So we have worked hard to engage a lot of key stakeholders. We have a number of different committees. A steering committee, a provider committee, a consumer advisory committee, a policy and legal committee, and a technical committee. And we actually had these committees work independently on a lot of the issues around privacy, and then had a joint meeting of all of them. That's really where individually in these different committees, their different perspectives came. And when we tried to pull them together, the voices became even louder in some areas. And some of the perspectives were juxtaposed. We also thought it was important to do some consumer, to look at some consumer input across the board through focus groups, not just through a smaller set of individuals that tend to be representing more on an advocacy basis special interests groups, which we feel is important, but we thought it was important to go beyond that as well.
I will come back to this a little bit, but we really have, as a principle, the need to want to strive to exchange what we are referring to as complete data by source and type. So the concern about having some organizations, or some providers, be able to submit their data but not have others really created a lot of concern from the provider and the healthcare organizations about the quality of care, the comprehensiveness of the data. Not to say that every data item, all notes and things like that, would go into the health information exchange. This is more about getting a comprehensive, a complete view and not having incomplete records. And also to really choose a flexible technical solution. Because we knew that based on time frames and some contractual obligations, we weren't going to be able to only wait until we had policy defined before we moved on to technology. So we wanted to try to really adopt some flexible technical solutions. Next slide, please.
So really what we have been working a lot on is really what we refer to as a balancing act, to make progress. And I think there were three, there are really three points here that I think are critical. One is, it is really, I think, philosophically we might all agree that policies should precede technology and technology should support policy. But there is a category that I've come to call operational feasibility. That is the practicality of implementing. So we can be somewhat ideal in what we want the policies to be andeven get the technology to support that, but if we can't practically implement it from the perspective of those submitting the data or those needing to use the data, then we’ve failed. And we started to actually go down a road of doing that before we realized a lot of the constraints or challenges we had to consider in operational feasibility. I've given you some examples here. So our data submitters, the healthcare organizations, really have indicated they don't have a lot of ability to filter data by data type or by data person so that puts some practicality in how we are going to do our, a consent model. And our providers have really said they need access to data independent of the patient being there. So just sort of relying on the patient being able to give them a password or something to get in to their data, they need to be able to allow the patient to have consented and know they are having their information available, but not necessarily when the patient is sitting there. And the consumers have really indicated that they do want control over who can access their data, but they won't want to have authorize every single visit. So again, a lot of issues like that we have been trying to work through. Next slide, please.
We also gathered some additional information through our focus groups. The sort of main message there is that the individuals that seemed most concerned about the use of the information and how it could potentially "harm them" was sort of employed adult individuals that were most concerned about how this would be used in terms of keeping them from being employed, getting life insurance, getting mortgages, et cetera. But when they thought about it in terms of helping them to support their aging parents or their kids, it became much more appealing. We also were participating in the national privacy and security project, HISPC. And in doing that we learned a couple of things. Number one, it was quite clear that HIPAA was used much more as a floor than as a ceiling. There were lots of variabilities with HIPAA, but really most of the healthcare organizations had sister privacy, stricter privacy practices in many of their release of information, authorization for release of information. I don't think that's uncommon to what HISPC has found across the country.
Also we looked at our state laws and found out that we had some exceedingly strict state laws, particularly around STD and mental health. In fact, I think this was a surprise to many, but our STD law is more stringent than our HIV law. It provides for no sharing of information for coordination of care without consent. And HIV actually, although people don't realize it, do have that proviso in there. In mental health there was mixed interpretation around sort of the term of what disclosure really means. And I will come back to that in a minute.
And also we spent some time really looking at federal laws on the health information exchange specifically around CFR 42 and what that definition of federally funded alcohol and substance abuse treatment programs mean. Because again, there is active consent required to be able to share that data. And the definition that sort of finally people agreed on, or their interpretation of the definition I should say, was one that an organization that holds themselves out to treat, diagnose, and refer substance abuse. Although we have regulations under our state mental health law that also trickle down into our hospital regulations so that anyone that's providing treatment for mental health services under state law has some stringent constraints as well. Next slide, please.
What I really want to do, though, is focus on the framework for what we are calling authorization or consent, and in fact we have come to learn those terms are used, although they are different terms, they are used synonymously. And quite honestly, we actually have not completely made this document consistent with ourselves because you will see authorization at the top and consent at the middle, and we are really trying to convey the same concept. But we have broken this down into thinking about, around authorization or consent, sort of five, four areas, or five areas of flowing of data. The first is really notifying the community, much like Micky said, doing a lot of education and informing people of their rights and what this health informational exchange will mean. The second is the part where data would move from the data submitters through the HIE, or into the HIE, and again, our technical model is somewhat in flux based on some of where we are going here in terms of the -- it won't be a centralized repository, but do data stores of the organization sit at the organization physically within their fire walls or in a central data center is still under discussion. And then there really is the release of the information from the HIE to the provider who wants to see the data. And then two steps around auditing to make sure we know who's looked at the data and making patients, giving the patients the ability to see who has looked at their information.
So when we started the discussion, we were really starting it with the arrow between the second and third step. We thought we could really start by saying that we would, because we wanted comprehensive information and not have some data in and some data out from different healthcare organizations, we started with the thought that we could allow individuals to consent on who would view their data. And actually learned that there was a lot of concern that even the data moving from the data source through or to the HIE, was what was very important in people's mind. That both of these aspects were important. So even though initially we were sort of saying your data might be made available to the health information exchange and you have the right to say nobody can see it or this doctor can see it or that doctor can see it, that was not sufficient for our community. And so really they wanted to, we are now working through and having to reassess how to go about doing this so that they are able to consent to participate, to have their data be able to go from individual facilities to the health information exchange but in a manner, again, on some of those operational feasibilities, what we are wrestling with is how to do that and not have to get consent organization by organization and only have certain organizations put in data. So I might have confused you a little bit on that. Hopefully I was clear. But basically the business associate agreement was identified as not being sufficient enough to move data from the data sharing partner into the HIE and without patient authorization. Again, the whole general sense here is that HIPAA is not stringent enough. Our community keeps saying over and over again, that whatever we do, whether you are considered HIPAA-covered or not, they feel that we need to be more stringent than HIPAA on all of this. And again, there is some requirement now that the data submitter, the healthcare organization understands the consent of their patients. Okay. Next slide, please.
So our next steps are really to try to go back and reassess and address some operational capabilities of our data sharing submitters and to understand more the legal, from the legal and technical experts, what constitutes disclosure, because we have had a lot of variability. What was interesting is, when we got a group of lawyers in the room and we were looking at one particular law around mental health, and we asked them to define disclosure. Their interpretation of disclosure was different. Some saw the minute data left the organization is disclosure. Others saw it a little bit differently. What was clear was the minute one of them, the minute they realized that each other, that they didn't agree with each other, they all became more risk-averse. And they all realized that their colleagues around the table would be the ones in the courtroom across from them. So they really came back and said, in order to address this, we might need enabling legislation. So it was sort of an interesting, for someone who doesn’t work with a lot of lawyers, it was interesting to see that happen.
We need to reassess our technical options. And the other thing is, we really have not gotten down further because we are waiting to try to get this part settled, although there are some things we can do. We know we need to develop policies to support this whole effort, specifically around the areas of notification and education, role-based access, breaking the glass and emergency exceptions, auditing, breach procedures, penalties and enforcement, complaints, as well as the patient's ability to view their own data, append their own data, or amend it, rather, and view who's seeing their information. Next slide, please.
The other thing, I'm not going to go through all these points but it's been clear been over and over again that in our community people are beginning to say we really need enabling legislation. And when we talk about what is it that we want the legislation to do, what I've got in front of you is a host of different areas that are under consideration for whether we need to legislate in these areas, regulate in these areas, or have policy drive these areas. But I think there is pretty universal agreement that some sort of enabling legislation would be important, whether it is around a standard form of consent or authorization, whether it is protections against subpoena or, importantly, enforcement and sanctions for misuse of data, the penalties andviolations, provider safe harbors, all those areas. And interestingly, some of this then sort of plays into what's the State role in all of this. And again, the State is actually having to put together an RFP to actually designate the RHIO. So from a broader perspective, how much of this will carry over? I know there was some discussion about certification of health information exchanges and what that means. We are sort of wrestling at the State level with, what are we going to ask for to be able to designate a RHIO. What is it that they have to demonstrate and show they can manage and operate this? Next slide, please.
A couple of summary points. We are working to try to deploy strong privacy and security solutions. Again through a community-governed approach. We feel that's critical and that the consensus building that we need to do now, although it takes a lot of time because we have such diversity among our stakeholders. We do believe that inclusion is the rule and it will pay off in the end. Again, we think that the value to the health information exchange, the business case and the value to anybody is really derived by having complete information. So we are wrestling with that idea of how to allow an active opt-in consent model but allow for a complete record as well, and the balance between policy and practicality. We really are taking the approach of addressingconsent at the two levels, the consent to participate and the consent to view. Trying again on the enabling the legislation, to determine what needs to be legislated, regulated, or designed in policy. And importantly, we really recognize that in the end we will have some stakeholders that will not feel happy with where we have ended. We are not going to be able to please anybody. And we need to try to balance those considerations with the implementation of a system that can work and benefit the population overall. And it may be perfectly appropriate for some individuals to just not engage in a health information exchange because they perceive the risk too high. We have vetted a lot around the sort of sensitive information. Can you block or not block or share or not share certain data. One of the things we have heard over and over again, and this is my last point, what's sensitive to one person is not necessarily sensitive to another. So a broken bone or a rib to a victim of domestic violence is as sensitive as an HIV test or a mental health diagnosis to another. So how do you really sort out what's sensitive? And, again, we believe that there needs to be enough patient control but in a manner that allows the physicians and others to provide the quality care that needs to be given. Thank you.
>> Kirk Nahra:
Thank you very much. Let me ask a little bit of a scheduling question. For those of you who have testified today, either inperson or on the phone, and Phil Marshall, I know I have your schedule limits. Are there others who have shortterm timing concerns? Availability concerns?
>>
No, not here.
>> Kirk Nahra:
Okay.
>> Gina Perez:
This is Gina. I have until a little before four.
>> Kirk Nahra:
Okay, great. Thank you. Let me suggest this then, for our group. Phil needs to leave in about 10 minutes. So what I could -- let me suggest this. Let's open up to our Workgroup for any questions for Phil. Then we will let him go, and take a quick break, and then come back and do the rest of the discussion and questions for the rest of our panel.
Let me just start off with a question for Phil. Phil, you and I talked about this quickly at the break before, but you made a reference in your testimony to a concern about, I guess it was policies might unnecessarily restrict some of the activities of the PHR. Could you elaborate on that a little?
>> Philip Marshall:
Sure. My comment had to do with rules or regulations that might somehow stifle the ability for consumers to increase the efficiency and address cost and quality concerns in our healthcare system. Really, our point of view on that is really quite simple, and that is that we believe in the spirit of HIPAA. We think under the spirit of HIPAA we have been able to achieve a number of things. It's allowed consumers to have a little bit more transparency, a little bit more control over who receives their information, the kinds of disclosures that can occur. And in fact, WebMD, when bringing in data from a variety of data sources, does serve as a business associate to the covered entities with which we work. Having said that, there, we are having an active conversation and have evaluated the scenarios which occur where consumers can begin to take a little bit more control over gathering their data from multiple sources and then sharing that data. We have had a number of conversations about whether or not, even in the environment in which we serve, those are HIPAA-oriented transactions, those are things which are covered under HIPAA. It is not as if we represent a point of view whether they do or they don't. But the point really is this, and it's really a question. And that is, what happens when consumers do begin to take a little bit more control in gathering data from doctors’ offices, when sharing data with care providers? Knowing that that is at least in part within the spirit of HIPAA, is that something that, is that good enough? Is that being within the spirit of HIPAA? Consumers taking more control and having more control over their data, is that, is that something -- we believe it is something that is going to help improve the efficiency of the healthcare system. And so we are evaluating the different ways in which those processes might be curtailed. So we have some concerns over that. But the question, I guess, really put more simply is that while a variety of transactions and things have occurred in the past that have been under HIPPA, when consumers begin to take more control over that process, what happens then? When consumers can choose whether or not to share their data, is that something which rules and regulations are going to help facilitate, or is it something that rules and regulations could help stifle? Again we don't have a strong point of view there. We just would like everybody to be aware of that.
>> Kirk Nahra:
Are there other questions for Phil at this point? Anyone on the phone? Okay, Jodi.
>> Jodi Daniel:
My question, if you are offering PHRs through either employers or through health plans or other organizations, what happens when the individual no longer is enrolling in that health plan or is no longer an employee with that entity? What happens to that information? Is there a way they can continue to access that information, continue to use the PHR, or how does that work?
>> Philip Marshall:
Yes. In fact WebMD does believe in helping our users to gain ongoing access to their data for life, and we do have mechanisms in place to help ensure that.
>> Kirk Nahra:
Any other questions for Phil at this point?
>> Alison Rein:
This is Alison. Actually as a followon to Jodi's question, I'm wondering if a person decides to switch because they change employers and have a different service, A, can their information be transferred over or, B, worst case scenario from their perspective, can they just ask for all their records within WebMD be deleted?
>> Philip Marshall:
In fact, we do have mechanisms for consumers to request that their information be deleted. There are things we have to take into consideration there, not the least of which are record retention practices and laws, and we do. And I will just reiterate the statement that I made earlier, and hat is, we do stand for and believe in consumer's access to their health information for life, and we do have mechanisms to help a person achieve that.
>> Alison Rein:
Thank you.
>> Kirk Nahra:
Any other
>>
One more question. You mentioned that you share de-identified data with the employers, and you mentioned two different things. One was just to determine how employees are accessing, in other words, is the system being used, I presume, and is it a benefit that they are taking advantage of. But you also, it seemed to me I heard you say that it was being used for other purposes. I wondered if the de-identification process in HIPAA is the one you are using, or do you have a different set of standards, especially in smaller companies where it may be harder to shield the patient from being identified?
>> Philip Marshall:
I appreciate the opportunity to clarify that point. The question earlier had to do with various uses. Do we sell, do we use data for various purposes? The point I was making about the use of our data for aggregate analytic purposes, I'm glad to have an opportunity to clarify. First off, when we offer reporting to our clients, this is done in aggregate and without identification. It is done from our own systems. This is not something that requires the transfer of that data elsewhere. So that's the first point. The second point is we do have, we do follow a pretty conservative practice on ensuring that the cell sizes for the reports that our sponsors look at do not go down below a sort of minimum level, in order to help ensure that neither directly nor indirectly, nor through triangulation, could a person's identify be extrapolated from that process.
>>
Thank you.
>> Kirk Nahra:
All right. Thank you. At this point it is, I have 3:25 on my watch. Why don't we take a 10 minute break? We will start again at 3:35. Please try be back at that point, and we will go on to both other questions and a broader working group discussion. Thank you very much.
[break]
>> Kirk Nahra:
Why don't we go ahead and get started. Anyone? On the phone?
[inaudible]
>> Jennifer Macellaro:
This is Jennifer. Can you hear me? I'm having a really hard time hearing you there in the room.
>>
Yes, we
>> Kirk Nahra:
Now we just heard you. Are there other folks on the line?
>>
We are on the line, but we can't hear the room.
>>
We can't hear the room.
>> Kirk Nahra:
All right. We will work hard on is that any better?
>>
It is a little bit better.
>> Kirk Nahra:
All right. I'm an inch away from the microphone. We must have some are the microphones they are on? Maybe they are not actually on? Is that any better? Can you hear us now any better?
>>
Not really. It is still very muted.
>>
It’s very faint.
>>
Having trouble [inaudible].
>> Judy Sparrow:
It is they can't hear us.
>> Micky Tripathi:
Micky Tripathi and Steve Bernstein are on.
>> Judy Sparrow:
Can you hear us clearly?
>> Jennifer Macellaro:
Now I can, yes, Judy.
>> Kirk Nahra:
All right. Is that a little better?
>> Judy Sparrow:
All right.
>>
We certainly are hearing people on the phone clearly. At one period, I certainly can hear everyone else who is on the phone very clearly, but having a difficult time hearing people in the room.
>> Kirk Nahra:
All right. We will do the best we can on that. I'm not sure what the problem is.
>>
Micky, is that you?
>> Kirk Nahra:
This is Kirk Nahra talking in the room.
>>
It just fixed itself.
>> Kirk Nahra:
Okay. So that's better. All right, good. We will go ahead and get started at this point. What I would like to do is open it up for discussion with the Workgroup. We have sort of two goals over the next, you know, roughly hour. One is, I would like to make sure that people have a chance to ask whatever questions they have of any of the individual panel members who gave testimony today. We would also like to get some more discussion with our group about how the testimony today and people's thinking over the last couple of weeks has affected some of the issues in the working hypothesis. I don't envision that we will conclude that hypothesis today, but just to move it along, look at whether people have reactions, different reactions, different views, and also think about whether there are other questions that have come up. So let me just at this point open it up. Why don't we start with people on the phone in terms of whether you have particular questions for any of the panelists?
>> Peter Basch:
This is Peter. I have a question for Ken from RxHub, if he is still there. Can you hear me okay, Ken?
>> Ken Majkowski:
Yes, Peter, I can.
>> Peter Basch:
Okay. Anyway, good afternoon, nice to hear your voice again. I was trying to reconcile what I see as a potential problem between the concept of patient control of information and how RxHub deals with that issue, essentially asserting, probably a correct assertion, that it leaves that issue to others. It is, in essence, a neutral conduit. But just in my own mind, for purposes of determination of quality care, in terms of choosing a medicine or not choosing a particular medicine, or for eligibility, does Rx Hub have any particular view if a patient was able to tell the physician, I want a prescription for a particular drug but I don't want the fact that you are prescribing that particular drug made available to anyone outside of this office? Would that be a kind of a technical impossibility with the RxHub network?
>> Ken Majkowski:
I'm not sure exactly where the RxHub network would get involved with that question. Once the patient, physician had gotten eligibility from the PBM and then the formulary information for the PBM and wanted to write a prescription, how that physician chose to then transmit that prescription to the pharmacy would, there would be a variety of factors involved. If they had connectivity through SureScripts or RxHub, whether it was going to retail or mail-order
>> Peter Basch:
I could clarify the question.
>> Ken Majkowski:
Please do.
>> Peter Basch:
If the patient said they wanted a prescription and they wanted it covered by their insurance, it would not be possible to transmit the prescription after they got the eligibility information without them transmitting the fact, through the network, and I presume then to whomever else had access to it, that that medication was prescribed.
>> Ken Majkowski:
No, in fact that does not occur. When a physician chooses to write a prescription, electronically or in any other way, and they're connected to our network, there is no information that goes from the physician back to a PBM or anyplace else. So no information is shared about that prescription, except between the physician and the pharmacy and the patient. The only way the PBM finds out about that prescription is if, during the course of filling the prescription, the patient wants to use their benefit to pay for it. And then they allow the pharmacy to adjudicate that claim through a network like Per-Se, McKesson, or WebMD Envoy, or whoever they utilize as their VAN there, to get the drug adjudicated. But no information passes from the doctor's office through RxHub back to an insurer at any time about the patient.
>> Peter Basch:
I understand, but what you are telling me, Ken, is in the process and I may have misstated this, when the patient decides they want their insurance to pick up payment for a particular prescription, that process then passes the information that that drug has been prescribed back to the PBM for coverage purpose.
>> Ken Majkowski:
That's correct. And that happens at the pharmacy level through other networks, not through RxHub and not through SureScripts.
>> Peter Basch:
So my question was, that if a patient presented to the physician I would like you to prescribe this medication. I would like, and the patient decides when they go to the pharmacy they would like it to be covered by their insurance, that a message of, I don't want the physician side to share the information is incompatible with the message to the pharmacist
>> Ken Majkowski:
Peter, I think I know what you are asking. And I think that's not the exact place that that can occur. Where patients have the ability to opt out for sharing information is with their insurer. You know, they can go to their insurer and say, I don't want information shared on me. And there are insurers who then, through their PBM, would block information about specific patients.
>> Peter Basch:
I see.
>> Ken Majkowski:
But it doesn't occur at the prescription by prescription level.
>> Kirk Nahra:
Just to play that out, Peter, this is Kirk, I think you are raising an issue that may be relevant in this context but it’s just as relevant not in this context. If a patient, in the old days if a patient wanted to do the same thing, the way to keep that information from the insurer is pay for it yourself.
>> Peter Basch:
Exactly.
>>
Right.
>> Kirk Nahra:
You know, I don't know that there is anything unique about this system that makes it harder or easier for a patient to, A, get the insurance to pay for it but, B, keep information from the insurer. That's just part of the deal.
>>
I think you are right. This would happen in a pure paper world or in electronic, it doesn't matter.
>> Kirk Nahra:
If you are trying to get reimbursement, they are going to know about what it is for.
>> Peter Basch:
No, I understand. I'm trying to make sure from a physician's perspectives, physicians wanted to participate in the concept of patient control of information, that there are some things physicians can do. But when a patient presents to a pharmacy for coverage for a medication that the, that information may pass through a network anyway.
>>
Yes. It definitely will. And that's how
>> Peter Basch:
That's how it gets paid.
>>
How it gets paid.
>> Peter Basch:
Yes. Okay. Thank you.
>> Kirk Nahra:
Other questions from people on the phone for any of our panelists?
>> Dan Rode:
This is Dan Rode. I wanted to ask John, and if some of the HIE folks want to respond, that will be fine. John talked about metadata and identification of who submitted the data in their system. I wanted to know, if another provider is permitted into the system, then can I presume that they can identify who has submitted other data in the patient's personal health record? In other words, can they see which other clinician submitted that data or who was the originator of the data? And is that going to be a secondary privacy issue from the standpoint of my ability as a physician to tell what another physician is doing?
>> John DesMarteau:
In answer to the first part of the question the, every time a piece, a document, a piece of data is entered into the record, there is an obligatory ownership of who created the data that has to be, that is part of our system. I'm not quite sure of the impact of the second. You'd almost have to give me a specific example. Because again, this is a personal health record. So that if I am consenting and, again, this is the LAXOR system. If I am consenting for physician A to look at my record, I will know there is data in there created by physician B.
>> Dan Rode:
And what I want to know is, does physician B recognize that physician A will be looking at their data, which they may or may not be aware of?
>> John DesMarteau:
There is an audit trail for each of the different roles. I think that's what you are getting at.
>> Kirk Nahra:
But whether you are sort of looking at a doctor's privacy. Right?
>> Dan Rode:
I'm looking at the doctor's privacy right. But I'm also looking at, if I go into a personal health record, the patient allows me as a clinician to look in their record. I have all this material. Will I be able to tell what data in that record came from another clinician as opposed to perhaps from a claim or the patient themselves?
>> John DesMarteau:
In our system, yes.
>> Kirk Nahra:
Any other questions from folks on the phone at this point for any of our panelists?
>> Alison Rein:
This is Alison Rein. I was wondering if the folks from Massachusetts, Delaware, and Rhode Island could maybe talk a little bit whether or not they have dealt with, or challenges they might anticipate with, patients who get care from providers in their respective states but also in border states.
>> Gina Perez:
This is Gina from Delaware. Delaware has basically determined that we need to start in state. We have a lot of people who cross borders for patient care. We refer a lot of patients to Jefferson and Philadelphia and (inaudible). We have bordering hospitals throughout Maryland. So it is very much of interest to branch out into other states. But the focus is on in-state providers getting as much data, making as much data available, getting as many providers as possible on the system, getting as much of the functionality up and running as we can. We have really a five-year roll out of functionality. And, in that process, working with other states and determining what the laws are that may prohibit that, but that's the plan. We absolutely would like to look at bordering states, but it is not immediate future.
>> Alison Rein:
I actually, sorry if I was not crystal clear. I can certainly appreciate that complexity. But is there some mechanism within your system then for notification of the current providers that maybe their, you know, comprehensive view of the patient, isn't as comprehensive.
>> Gina Perez:
Absolutely. And that is one of the user agreement lines, is that this is information available in the network. So right now it is not comprehensive. We have half of the hospitals in the state participating. We are not going backward in time. Soit’s a point in time forward. So the users recognize that this is not a full historical view, but it is a lot more information than they have today, and they are pretty excited about that.
>> Amy Zimmerman:
This is Amy in Rhode Island. And I would echo what Gina said. Again, we are looking at this in an incremental fashion and we are trying to get things up and started locally first. Clearly Massachusetts has a lot going on. We have not had direct conversations with them. But again, they have been focused, I believe - Micky can speak for himself, or Alan or others. But you know, again I think, HISPC has been trying to look at this and address it. But I think the efforts that are going on, you know, have really been localized. You know, I would presume Gina would feel the same way, in Rhode Island we are lucky enough to be able to do it statewide. When you look at some states, it may be a little bit different because their borders may be closer to another state than to other parts across their state. But we have not addressed that yet.
>> Micky Tripathi:
This is Micky. Amy, whatever you want to do, we are happy to just go right along. But Alison I'm not sure exactly what piece of this you are interested in, but we have only really sort of confronted and really, not really confronted in a serious way or in a way that would require us to change anything right now. The cross-border issue in North Adams where we have some patients who live in Vermont, who see one practice up there that has a satellite office up there but the primary office is in North Adams itself. So for patients who, even though they live in Vermont but really primarily get most of their care in Massachusetts because they just cross the border, they are following the Massachusetts consent procedure that we have in place. And that's about as far as it's gotten in terms of any practical kinds of things that we have had to deal with.
>> Alison Rein:
Thank you.
>> Kirk Nahra:
All right. Any other questions at this point or on the phone?
>> Peter Basch:
This is Peter again. If there is someone else on the phone, I will wait for my turn again. But if not, I have a question for Micky.
>> Kirk Nahra:
Why don't you go ahead, Peter, and then we'll turn to our people in the room.
>> Peter Basch:
Okay, thank you. Micky, it was certainly -- thank you very much for the presentation -- it was gratifying to hear how much you are, and people in Massachusetts are embracing the opt-in model. Because what I've heard from other presenters over the years has been that opt-in is too difficult and takes too much explaining of patients to do. And as someone who believes that if this system is going to work we have to have consumer buy-in, I'm delighted to see it can work and the people, once they understand it, do accept it. Question. Is the opt-in, in terms of sharing data, granular to the point that a patient might be allowed to, let's say, share a total cholesterol result, but not their LDL cholesterol result.
>> Micky Tripathi:
That's a great question. Currently it is not. Currently the opt-in basically says that you are opting in for everything, in principal. And then we tell them, you know, and here are the things you are opting in for, as a practical matter. As I shared during the presentation, notes aren’t in, things like that. But mostly because of the, you know, the difficulty of the technology's ability to do it and all the physician and practice processes that would, that you need to have put in place behind it to be able to have that type of discrimination. You know, we felt that the patient needed to understand that, right now, given the state of technology and the state of clinical practice, that they needed to know they were opting in for anything because we could not promise
>> Peter Basch:
Okay. Now, if the opt-in is given, Micky, can it be changed? In other words, if a patient says I opt in and then decide afterwards that was a bad idea, I want to opt out. Can that be changed and, if so, who manages that change? Who is responsible for it?
>> Micky Tripathi:
Yes, absolutely. So there is, even as I described there was a, there was an entity-by-entity opt-in. We have provided for a global opt-out so that a practice would not have to go and opt out entity by entity as well. I mean a private patient. Because we wanted to be able to make sure patients were able to do that quickly and easily if they so desired. So our network administrator vendor essentially would manage that global opt-out, and it would essentially trigger a process that we are still completely flushing out. But basically the highlights, or the outline of the process, are that at that point, at the point that the patient has expressed that preference, all data that they have held in the repository will be made invisible to any outside users and will be archived. And at that point no new data will be brought into the center, and we will archive any data at the center that's already been there because, you know, from a medical record integrity perspective, we need to be able to have that, you know, should any issues arise a year or two from now where a physician feels that there was information there that I used for a clinical decision that needs to be made available. But it will no longer be made available except under special request, generally.
>> Peter Basch:
Last question. You mentioned that if a patient decides to withhold a component of the record once it is there in the community record, that the fact that there is information that is not being shared is invisible to the requester. This is certainly one model. Other models have indicated that there would be some kind of indication that you are seeing something but not everything. I'm curious if this has been used enough that you have gotten comments from people who have had to provide care based on that model about whether that seems to work for them, whether good enough functions in a way to improve quality of care or whether it could, or has, led to, let's say, some misleading diagnoses or poor treatments based on an assumption that what was there was a complete record, when indeed it was a record minus some important details?
>> Micky Tripathi:
Right. So I may have miscommunicated something, which was first, a patient cannot consent at an element level. So they are consenting at an entity level. But that said, you know, so far we have, and we don't have enough a track record to know if people feel comfortable with that. But I will say, we are going to have essentially a warning screen that says to everyone who logs on, please understand that this is not a complete record. And, you know, and our sense is, especially given how much of, how most of the world is still not in this area, the vast majority of U.S. care does not have this type of health information exchange. Even for these communities, there is a ton of clinical information that won't be there anyway, regardless. I mean, for Brockton 25 percent of care happens in Boston for tertiary care. So I don't think that anyone will be under the impression this is a complete record for a long time, anyway, as a practical matter. But that warning will be there for them.
>> Peter Basch:
Thank you.
>> Steve Bernstein:
This is Steve Bernstein. Just one quick clarification. With regard to the granularity, the opt-in is sort of all my information kind of opting in. But I think for Massachusetts' purposes, despite that, in certain instances, namely genetic testing and HIV, that actually won't go without the patient getting a sort of [inaudible] --
>> Peter Basch:
Yes.
>> Steven Bernstein:
just to clarify that.
>> Peter Basch:
Okay. Thank you.
>> Kirk Nahra:
Why don't we turn to questions from people in the room?
>>
A couple of followon. A couple of followon questions for the nor’easters. If you were to I recognize the need to sort of take a bite of this apple, and a small bite, and focus only on your state. But if you had the opportunity to have dialog with other states who are doing something very similar, and I heard you say many times throughout your presentations “similar to what the other state has said, we are doing these things”, what do you foresee being some of the holdbacks or some of the difficulties to not collaborating early on while you are working in your states? And what might be the benefits of having those discussions early on while you are trying to do this at the state level rather than trying, more broadly reaching out to one another so that what you create in your state will transcend into these other states, that you know you are going to have to work with because you already know that you have border patients going across state lines for care?
>> Amy Zimmerman:
This is Amy. I will start with that. I mean, I don't think it's a lack, it is not a lack of desire or willingness. It is, from my perspective at least, it takes a fair bit of time to pull your own community and your old, you know, your, the major stakeholders together and to get the dialog going. So while Micky and I, and Gina and I, and others, may have side conversations, the fact that Micky was starting or came to a point of, you know, moving to an active opt-in, you know, at that point, you know, the dialog was not necessarily the same in Rhode Island. So, and the fact that Rhode Island now, that our community really says, well, we not only just want people to opt in about their data being made available, but we want a second level of consent at the disclosure level. You know, Micky is operating I mean, there is a risk here. There are pro's and con's both ways in the sense that, you're right. It is where you want to start the apple. In some environments the healthcare may be delivered in such that there is so much crossover in the states that they are not working with their other state colleagues. They are working across, there are some RHIOs that are working multi I don't know, I have to think about this before I get quoted on this. But that may be working more multistate than we are based on where, where that healthcare market is. So I think it is just a matter of where you are starting. And it's not for lack of desire. It is just a, I see it as a feasibility issue.
>> Gina Perez:
I would agree with that wholeheartedly. This is Gina from Delaware. We are, I always say you can never underestimate the time it takes to build consensus. And it is, you know, this has been a long process, getting to where we are today. And there are complexities that going beyond strict state lines would add to that. So again, it is not that we don't want to do that. It is a feasibility issue. It is a time issue. And my goodness, if there are folks in Jefferson that want to jump into the discussions, I'm happy to, you know, have them involved. But it is not something that we have pursued for just more logistical purposes than anything else. And I'm sorry, the State of Delaware is putting a significant amount of money in to developing the system so, you know, then we get into some of those issues as well.
>> Micky Tripathi:
Yes, I would certainly echo what my other nor’easterners -- I guess Delaware is Mid-Atlantic or -- have said, but with a couple of other things. I think Gina hit on one point which is that a lot of the funding is sort of, you know, is kind of earmarked or within the boundaries of a state. So certainly state funding is that way. And to the extent that you have health insurers involved, at least in the northeast a lot of them are state-focused. And Massachusetts are for leading health insurers are Massachusetts companies with Massachusetts markets. And my primary funder is a Massachusetts company with a Massachusetts market. I think that also privacy laws, to the extent they are very state-specific, again, can kind of dictate how, you know, howwide you could go. The last thing I would say is, I think when we think ahead about sustainability which is kind of the big question for all these health information exchanges, and this might just be my personal sense right now, is that the real, that the real sustainability piece of that is local. And it's as local as you can get. Because, you know, you have sort of a, you know, sort of what is that integrated, that selfsustaining market which really may be sort of a Brockton community where you get enough people who share enough patients and are essentially trading partners, who see the value of that type of connectivity and would be willing to pay for it on their own, versus right now, I will say even at the Massachusetts level, it is hard for us to figure out what is that selfsustaining model for a Massachusetts network. It is not obvious who is willing to pay for that right now. And it's not obvious even at a local level. But it seems a little bit clearer, and there are enough people willing to say right now I can see paying for a Brockton network. Not sure I could see paying for a, you know, a Massachusetts network. And then when you talk about New England network, it is even harder to see how that would sustain itself.
>>
And you sort of segue me to my second question, which is that whole issue of sustainability and the complexity that goes along with that. And if you could talk a little bit about what you anticipate as far as complexity. I know one of you mentioned that you were able to get your authorization or consent form had all of the providers' names on it, which was really nice because you are taking really small bite of the apple. But when you are making apple pie, where are you going to go from there? How do you manage those complexities and what do you expect out of that?
>> Micky Tripathi:
So well this is Micky again. You know, I don't know, and I think that, my sense again, as we kind of roll this up, and I will just think of Massachusetts. You raised a couple of issues there. I will just deal with the privacy aspect if that's what you are thinking of, the consent part, is that, you know, essentially you would have these local networks, you know, let's say Brockton or Newburyport, that has a local network. And then you are going to have a statewide network, MA-Share, that will have a certain privacy and security standard for the statewide grid. And, you know, it could almost be, you know, something that the community of Newburyport has to come to terms with with MA-Share, that there is a certain standard here and maybe sort of a higher level standard that deals with the level of, or the density or the type of information, the breadth and depth of information that you need exchanged at a state level. I think at a local level you have much richer information exchanged with higher frequency than, for instance, between a Newburyport and Mass General. And that may say something about, you know, about the type of consent you need because it is, you know, necessarily thinner at that level and it's more transactional, but it is certainly less frequent. So I know I have 10 transactions a day, let’s say, or a week with Mass General Hospital, let's say from Newburyport, and that suggests a different type of process perhaps than I have a 150 a day within my own community. I don't know if that actually gets at the question you asked.
>>
It does, thank you.
>> Kirk Nahra:
Paul.
>> Paul Uhrig:
Micky, a question just briefly. Back to the all or none sort of opt-in by entity. You touched on it, but I wasn't clear. Is the barrier technology, that a technology can't distinguish between a diagnosis for the flu and one for AIDS, or is it having to manage those consents at such a granular level, or is it both?
>> Micky Tripathi:
I would say it is both, in a sense. I mean, in a way, once you get past one barrier, you know, you sort of find that there might be another barrier just behind it that you don't see yet because you are sort of looking at the one most proximal. So for example, I think there is certainly, part of it is technology, to the extent that different vendors have a different ability to filter certain things. But, you know, as long as it is structured data, for instance, if it’s just ICD9s or CPTs, most of the, certainly the CCHIT-certified vendors are able to do that filtering. But the question is, what they are not going to do, is they're not going to put the flags on for you. They are not going to go through the ICD9 book and flag which is in and which is out and under what conditions is this in and this out. That's something you have to do, you have to have someone else do. We have done that by having a group of physicians in North Adams go through and flag the, for those structured fields anything related to HIV results or genetic testing results. Because as Steve described before, that's by statute. You need to do that. So that was a lot of work, both doing it and then figuring out how you are going to maintain that.
So, and then there is a process, you know, piece behind that which is basically getting agreement of a community to enter their clinical information in a particular structured way and using, you know, locked down dictionaries to do that. In this case, you know, the physicians in this community, and indeed the systems require that they enter their problem list as ICD9s, for example. It won't flow at all, no data will go to center if they just type in text or, in this case, even if they pick off the SNOMED or Medcin list, because we settled on ICD9 as the standard for that. So that's what I mean on the process end, can you get a whole community of physicians to deal with that?
I think the other thing that, the other barrier behind the barrier that we have not yet confronted is, as you get more, you know, we just did HIV and genetic testing. But as you get sort of a broader and broader set of conditions, you start getting into the permutations and combination problem, I think. So for example, mental health, or even HIV might be an example. Well, you can flag things that, you know, that are obviously related to a person's HIV condition. But then what about, you know, a situation where, you know, a person might have a sarcoma and pneumonia or something like that along different things. You can put two or three different fields together, that individually you may not have decided needs to be flagged. But taken together, two or three fields could reveal something about a condition that you were trying to flag. You know, I think you can appreciate as you get more and more complex that way, all of a sudden you are blocking out a whole bunch of things that now are clinically useful for a variety of other conditions, like pneumonia for example. That's where you might get bigger and bigger problems.
>> Amy Zimmerman:
The other thing this is Amy is that we have heard, to the extent one of the things we talked about in our next round of, beyond labs and meds, is reports, discharge summaries, hospitals, pathology reports. Some of that information in the text base is very hard to start to filter out. So the more you’re, to the extent that any health information exchange, you know, putting notes aside, is doing any sort of reports or anything that's text-based. Again, the complexity of actually trying to unimbed information in places where you may not expect it or it may just pop up, I think, has been raised as a challenge, along with the fact and you could probably speak to this more that even in a medication history list, I mean, medications are used for multiple, different purposes. So there may be a medication that's commonly used for a mental health condition but may be used for a non-mental health condition so how do you sort that? Does that mean you block it even though someone is using it for some very different purpose? So those are some of the complexities that we have heard.
>> Kirk Nahra:
Jodi.
>> Jodi Daniel:
I guess this is for the folks involved in health information exchange efforts, I've heard a couple of things. One, that folks, these, the HIEs are not covered entities. And I'm also hearing about policies, privacy and security policies that go beyond HIPAA. So my question is, how do you envision some of these obviously have technical solutions, and you can build it in. If you want audit trails, you can build that into the architecture and the technology so that they automatically are, they are automatically created. But as far as sort of rules of the road for participants in the health information exchange, how do you plan to enforce those? Is this sort of a condition of participation? And if somebody were to inappropriately access information they would be kicked out. Is there, is it just by contract? Like, what's sort of the mechanism for assuring that the policies that are developed as part of this collaborative effort are actually adhered to?
>> Amy Zimmerman:
This is Amy. I will start with that. That's where my comment about sort of what needs to be in legislation, in regulation, and in policy, enforcement of those that need to go along with that. What we have heard loud and clear from the community is you need strong, just to make something law or even a regulation or even a policy without the remedies and the ramifications and some sort of enforcement of that, you know, really weakens it. I don't have an answer how we are going to do that, except that we have clearly sort of identified that there are a host, this is something we need to do, that we have to have some strong enforcement. And there may be multiple levers. It may be that, you know, if there is a violation, you know, maybe there is, that organization no longer is participating in the HIE. And maybe there are civil and criminal penalties that go along with it. It may be a combination of areas. I don't have specific examples, except I think that's how we have been trying to think about it, in a tiered approach and acknowledging that we have to develop, that that’s a policy, that in essence is a policy, however it translates into law or regulation, that's an area we need to really come together as a community and get consensus on and define procedures to adhere to and then adhere to them.
>>
And if I may just add to Jodi's question. When you are talking about enforcement and causing people to do the right thing by the data, there are those who, in the research community who would love to have access to this. And you might have patients who want to choose to engage their right to restrict this stuff to only be used for treatment and payment and healthcare operations. How are you going to hold people to that standard in these broader networks as they grow? How do you anticipate that?
>> Amy Zimmerman:
Well, initially, the short answer to that is, initially that's why we are limiting it to coordination of care, treatment, payment, and operations initially, because we have not gotten to that community process of how the RHIO or the entity overseeing the health information exchange will make decisions about appropriate uses of data.
And in fact, getting back to this sustainability question, a lot of individuals really see that the sustainability model here is, for the health information exchange, is more on the lines of being able to use information appropriately whether, you know, aggregately, de-identified. But to be able to use that as a way to self-sustain, whether it is through research or whatever. So there is a real sort of tension here between how to build a sustainability model, yet we don't have the rules of the road so to speak defined for even how those decisions about what other appropriate uses may be and under what terms and conditions, and how will that be enforced, developed yet. That's what actually caused our community to put some initial, early limits on the use of the data as we start to pilot, to gain that trust and to really get some experience with all of the players and stakeholders working together, and then be able to develop a communitybased process, build on a communitybased process, and come up with some rules about what will and won't be acceptable for additional uses and how and under what conditions.
So I don't have, again I don't have the answer, I know it is an issue that's of concern. In fact early on the term, you know, it sort of loosely got out ahead that there was some conversation because some individual said, well, gee, if we can make aggregate de-identified or appropriately secured information available, the cost of doing those runs, the cost of putting that data together, not in a for profit manner but in a nonprofit manner may be a sustainability for health information exchange. People will see value in that. That got interpreted to, quote, selling the data. And the minute that go out there, you know, that's when the whole conversation about needing to limit, early on, this use, until those processes and more full engagement on behalf of the stakeholders and the community could really wrestle with how are we going to determine. Because everyone sees there is huge value in looking at that aggregate data for evaluation, for quality improvement, to reduce the time on getting information through the research world out into practice, and for public health purposes. But again, they are not necessarily consistent at this point in terms of the, there is just this natural tension.
>> Steve Bernstein:
This is Steve Bernstein in Massachusetts. Just a little more commentary on policies and procedures. One of the I would say key hallmarks of the Massachusetts eHealth Collaborative project is really a buildout of local policies and procedures that begin to map out, I will say behaviors, for lack of a better term, including sanctions. And those were communitybased, community-driven. They are about to be rolled out in terms of training and education and what the expectations are about using the exchange and behaving in certain ways back at the physicians' offices. And the physicians have been part of that process, as have their practice administrators, really over probably a year and a half long process of building those policies and procedures and going, I would say, in a number of respects, beyond what HIPAA requires. So in terms of opportunities for audit trails, for payment, treatment, and healthcare operations activities, some of that being done through the exchange vendor, discussions about a process and a committee for, in the event of an inadvertent disclosure or a security breach, how is that going to work? We have gotten to that level as much as we could, but I think it ties back to Micky's point that the more local you can get here with some tolerance for variations among communities, not very much variation, but some, a lot of this is clearly a localized thing. And the more you can get local buy-in, the better off you will be. That's what we are finding.
>> Kirk Nahra:
All right. Other questions from folks in the room? Let me go back to people on the phone for a minute. Are there other questions from Workgroup members on the phone?
>> Sylvia Au:
This is Sylvia. I had a question about, are any of the systems linking family information? Parents, child, relative, especially if there are test results where the patient can opt to let other family members see that information?
>> Kirk Nahra:
Sylvia, we got some background noise during the end of that. Could you go back over that?
>> Sylvia Au:
I wanted to know if any of the systems had anything in place for family information to be linked, parent, child, other relatives, especially for things like genetic information or family history, where a patient opts in to let the other family members use that information?
>> John DesMarteau:
This is John DesMarteau from LAXOR. Yes, in our personal health record we have a whole group structure which can be again, as I said earlier, either biologic family or nonbiologic for the purposes of, specifically of caregivers, and, but it could even be just a way of securely disseminating information about a certain family member. So yes, we do have a way of linking, but it is an opt-in basis, completely opt-in. In other words, a patient has to invite someone to be part of their group.
>> Kirk Nahra:
All right. Any other questions from people on the phone?
Let me ask one question and we will try to turn it to some of the discussion of work hypothesis. John, another question for you. You mentioned a terms of usage with your PHR. Is that terms of usage tied in any way to HIPAA? Is it consistent with HIPAA?
>> John DesMarteau:
It is consistent with HIPAA, again, where it applies to our business operation, to the operation that we are, you know, our business, yes.
>> Kirk Nahra:
Okay. All right. Well, let me try to transition to the working hypothesis discussion. For those of you, I guess in the room, I don't know if the people, the couple people from Massachusetts on the phone will have access to this. But on the slide, on the screen there is the working hypothesis that our group has been moving forward with. And we have sort of a baseline hypothesis and then several subcategories. So let me just read this quickly in terms of the sort of introductory paragraph of our hypothesis. All persons and entities that participate in an electronic health information exchange network at a local, state, regional, or nationwide level, through which individually identifiable electronic health information is stored, compiled, transmitted, or accessed, should be required to meet privacy and security criteria at least equivalent to relevant HIPAA requirements.
And we have been looking at this working hypothesis as a discussion point for our Workgroup. The idea essentially being and a couple of people have mentioned this idea today establishing a level playing field for all of the people that are involved in these different networks. And we had today, you know, sort of two panels of entities who would be affected by this working hypothesis, in the sense that today we have HIPAA-covered we have sort of, as a working group been looking at three categories. We have been looking at HIPPA-covered entities, we've been looking at business associates, and we've been looking at entities that are neither. And the idea was to create a baseline standard by which the business associates and the entities that are neither business associates nor covered entities would essentially be, I would have said lifted up, but from the discussion today maybe it is not lifted up, but sort of pushed to a point where they at least had to meet those standards.
One of the subhypotheses would be, we want it to apply directly, so the business associates is not just a contract, we want the enforceable standards to be applied to them. I would be interested in people’s reaction to that. What I heard today, I think from everybody who we've mentioned I'm not sure if everybody said something on this is that all of you are essentially lifting yourselves to HIPAA for business purposes. The working group also recognizes that not all parts of HIPAA might be relevant. For example, the easiest one I think to think about is privacy notice. Paul, I know, doesn't deal with, SureScripts doesn't deal with individual consumers, I assume RxHub doesn't really have a relationship with individual consumers. That would be one where giving, delivering a privacy notice to somebody whose claim sort of filtered through your system would be silly because they won't have any idea who you are. But as a general matter, the idea was we are going to lift the working hypothesis proposes having enforceable standards for all players in that field that would be at least at the HIPAA level. So I would be interested in people's reactions, concerns, support, whatever. Again, I heard a lot of you say you were already there and many of you saying you are above that. Anyone who wants to jump in on that? I mean, I'm interested in reactions from all of you. So maybe start, John, do you have any particular sense of that?
>> John DesMarteau:
I think as I indicated earlier, we are using HIPAA, as I think some people have said, as a floor. Obviously in states where there are more stringent HIPAA is pretty clear that if state law is more stringent than HIPPA, then state law preempts. So in those states where we would be operating, we would follow state law. I think the points that Amy was making earlier about enabling legislation for those entities that can go back and talk to their legislatures is extremely important.
The other thing I thought was sort of interesting, having been through the whole I actually started working on HIPAA right at the beginning of 2000, when the regulations -- and because I was working with Kaiser, one of the things that Kaiser was really concerned about that has sort of been bandied about today was the whole consent issue and how that could really flummox healthcare operations. Forget the payment and the other aspects, the TPO, but the treatment aspect. Actually Kaiser was probably the primary entity that got the requirement for consent for treatment dropped. We had visions of lineups going I mean, it is one thing when you are dealing with a small, solo practice. But imagine the Massachusetts General Hospital having to start getting all sorts of strange consents that, all of a sudden, the Massachusetts legislature enacts. You could have lineups of people going out around the block. That was sort of one of the problems that we were concerned about. But short answer is, yes, we look at HIPAA as a floor.
>> Kirk Nahra:
Ken, any --
>> Ken Majkowski:
We certainly look as HIPAA as a floor as well. We were lucky to be developed and build our infrastructure as the rules were coming out, and with knowledge of them. I think what's really different between what RxHub does and what everybody else does, is we have no data repositories. We keep no patient data. We don't store, compile, or assess data. We do transmit. I mean, you might want to look at us, and what we do is we do identify a patient but not with patient data, with demographic data. Would we be a lot different than being able to look to, than a Verizon fax, somebody using Verizon over a fax machine and faxing a prescription or faxing eligibility information from United HealthCare to a doctor's office? We are basically transmitting that data. However, knowing what environment we would be in and knowing who our participants would be and what their business practices required, we built ourselves to conform to HIPAA. And then additionally, this is the one area in that subhypothesis we would agree, we seeked out certification and accreditation by an organization which came in and verified, as a third party organization, that we did in fact conform to HIPAA as a non-business associate or
>> Kirk Nahra:
Let me ask you this as a followup. When you say you have met HIPAA, do you mainly mean in a security sense? Because if you don't have data, the privacy sense is, there’s not much there.
>> Ken Majkowski:
Yes, in a security sense, but also in a privacy sense, because information does flow through the network. So we have appropriate internal confidentiality requirements for every employee. We do have training for all employees. And because of HIPAA laws, for troubleshooting and routing, information is stored but not looked at for 14 days and then discarded. So we do have the privacy, we feel we follow the privacy aspects of HIPAA as well, and we have kind of stepped up to that standard.
>> Kirk Nahra:
Any thoughts from any of the state folks?
>> Amy Zimmerman:
I mean, again, I think I, as I stated before, clearly our community, certainly on the privacy side does not feel that HIPAA goes far enough. So what we will be developing will likely go beyond that. The one area that I just don't feel comfortable fully commenting on is when it gets into all of the secondary uses and the research components, only because I'm not familiar with the specifics of what HIPAA entails to really be able to understand whether those challenges would or wouldn't be helpful in enhancing or limiting in that area when it gets on to additional uses, except to say that there is a lot of sensitivity around the secondary use of data. So
>> Kirk Nahra:
Well, just to add on. I mean, the plan that we have with our Workgroup is to look at sort of two questions consecutively. The first one being, are we going to recommend that everyone be lifted or have a mandatory HIPAA standard as a base? Then the second question will be, should there be a standard above that? And we have not gotten to that question at all. But again, I heard from many of you today that in the particular niche that you are in, there are reasons to go above that, whether it's state law or business, a variety of reasons. That will be, I presume we will end up coming back to a lot of this testimony, you know, down the road when we get to that second issue.
Now, any other reactions from either Massachusetts -- I'm guessing we lost Delaware at some point. Any of the Massachusetts folks have any thoughts on that? I mean, would that be a concern if all of a sudden there was a, some kind of a, you know, law, rule, whatever, that pushed you to that level?
>> Micky Tripathi:
You know, I don't know. I guess we are in the same position as Amy in that, you know, we have gone above that level. And I guess we would like to see others pushed to that level perhaps. I don't know if there is much more to add there.
>> Kirk Nahra:
And Paul, I should I forget, you were testifying today. What's your view?
>> Paul Uhrig:
Since I helped draft the sentence I think I support it. So yes.
[laughter]
No, I think
>> Kirk Nahra:
Well, there was one thing you said today that made me not sure about that, in your testimony. And so I --
>> Paul Uhrig:
What’s that?
>> Kirk Nahra:
I’m trying to remember.
>> Paul Uhrig:
No, I mean, leaving aside the point that you, the caveat you said at the outset, that there may be certain portions not relevant based upon function. No, then I certainly support this sentence.
>>
May I add one thing, please?
>> Kirk Nahra:
Sure.
>> John DesMarteau:
I think that it is important to recognize that there is a difference between a personal health record and an HIE, Health Information Exchange. Because, and I think that the slide from Massachusetts where the patient was in the circle instead of being outside the multiple lines that, crisscrossing lines. And I think it was Micky that said that a goal further down the road will be to have the patient, if not completely in the center, at least maybe moving towards the center. And I think the personal health records, you have to as this Workgroup is making recommendations, needs to consider that a PHR, at least of the type that LAXOR has developed and is developing, is very much patient-owned and patient-controlled. And that is a little bit different than an HIE, especially as we move to clinical EDI standards where there are multiple APIs, Application Programming Interfaces, being built all over the place and the patient really will have very little knowledge of how stuff is flowing around. And again, that relates to, once you go beyond coordination of care, beyond this single patient, single provider interaction.
>> Kirk Nahra:
Paul, just to go back. The sentence that, at least for the written. I don't know that you said this exact
>> Paul Uhrig:
Okay.
>> Kirk Nahra:
sentence, but it was accordingly whether other entities should be considered covered entities and the requirements imposed upon them requires a balancing of the important privacy and security needs against the role and function of the entity being regulated andproper and legitimate use of the data. What I hear you saying is you are really focused on the requirements imposed upon them, not should they be considered.
>> Paul Uhrig:
That's correct.
>> Kirk Nahra:
Good. I wanted to make sure of it.
Let's open it to the rest of the group. We have, you know, we have wordsmithing issues obviously. But in terms of where we are with the hypothesis, I would be interested in, at least as far as our introductory paragraph, people have questions, comments, reactions? I mean, our witnesses today, who again I think are a good sampling of the kinds of businesses that would be affected by this, seem generally supportive. We had guessed that if there were going to be objections, it might be coming from that direction. Other thoughts from people in the Workgroup about where we are with the hypothesis? I mean is that okay.
>>
I think, I mean, I know I expressed in a previous meeting some, we talked a lot about some of the words, the particular words that, you know, like what do we mean by relevant requirement and what do we mean by enforceable. But I actually got even more comfortable with it when I got some feedback from those of you who were sort of more involved in drafting it that you were not actually looking to be limiting but trying to be clear that not all requirements are going to apply in all circumstances and so I think, I think we are on a good track.
>> Kirk Nahra:
Yes. And I think, you know, I think that, like for example that relevant point is spelled out in one of the subhypotheses. And we tried to address those, you know, for example the point about enforceability. I want to turn that that next. But we spelled out some examples. I actually wanted to discuss whether we should keep those examples. I actually don't like most of the examples, so I'm thinking of pulling those out. You know, but we have -- and again, I think what we are looking at is no one, well, I assume no one thinks it is a good idea for SureScripts to be sending a privacy notice to everybody whose claim has ever gone through their system. I mean, I, there are not enough trees in the world to justify doing that so
>> Micky Tripathi:
Kirk?
>> Kirk Nahra:
Yes, I'm sorry. I was going to ask if there was anyone on the phone. Go ahead.
>> Micky Tripathi:
This is Micky Tripathi. I just wanted to get clarification on something that I'm not understanding. And Steve and I were just talking offline about this. At least for the health information exchanges, you know, we are business associates of covered entities. I mean, that's how we get, and are able to at least just even route, whether you are storing or not, but having access to any of that clinical data is as a business associate to covered entities.
>> Kirk Nahra:
Right.
>> Micky Tripathi:
So in a way, I guess I'm not understanding the question of whether HIPAA should apply.
>> Kirk Nahra:
Well, here is let's be very clear about that. And if you go, again, you probably don't have the materials but -- well, he cannot see it on the Web anyway. One of the subhypotheses that we put in as clarifying is essentially what we are debating, and again we have not decided this yet, but what we are debating is the idea that these principles should apply to each of these entities directly and not just through business associate contracts. The point there being that business associate contracts, which obviously are the mechanism in HIPAA, were viewed as not fitting very well into this model and not being sufficiently supportive. Because the only way to, you know, there was not traditional enforcement. It was just breach of contract kind of actions. And the discussion that we have had, particularly with some of the health information exchanges, is that they really turn the normal idea of a business associate on its head. The idea of a business associate is hospital one hires vendor one to perform a specific service for the hospital.
That's not really what's going on in a health information exchange. I mean, you have got, I don't know, the Massachusetts one presumably is the biggest one now. You have how many hundreds of people, or thousands of people that are going to be participating in that. The business associate control model doesn't work very well in that setting. It's like, you know, sort of all of them are responsible for policing the same things, which probably means none of them will be policing the same thing. So the suggestion we are looking at, again still up for discussion, is our recommendation would be to make sure that whatever the standard is applies directly to those entities, not just through a contract.
>>
Kirk, if I could just add to that. I think one of the significant pieces of that is, that if you don't look at that, when you have business associate relationships with multiple people, then when something goes awry, where does the liability lie?
>> Kirk Nahra:
Liability and how do you terminate and how
>>
And how do you
>> Kirk Nahra:
the whole mechanism doesn't work very well. So does that address what we are looking at?
>> Micky Tripathi:
Yes, thank you.
>> Kirk Nahra:
Now, again, I mean, let me ask you. Does that, that's the question. I want to understand if people have concerns about that.
>>
Concerns about what?
>> Kirk Nahra:
Well, concerns about again, our proposal is that these standards at a, at at least a HIPAA level, would apply directly to what are today both non-covered entities and not, you know, people who are neither covered entities nor business associates and to people who are today business associates directly.
>>
I have a really clarifying question that may be way off-base. But in essence does that make everyone a covered entity? I mean, isn't that sort of what you are saying?
>> Kirk Nahra:
Well, yes, yes and no. I mean, we are not, the vehicle by which this would be accomplished we have not gotten to yet. I mean, we cannot just wave a magic wand and change the HIPAA rule, and it doesn't necessarily make sense to have the HIPAA rule apply to the whole there is a lot of things in HIPAA that have nothing to do with health information exchange. So it is not necessarily saying and, again, we have not gotten this far -- it is not necessarily saying, you are a covered entity for all HIPAA purposes. We could have, for example, a set of rules that these are the things relevant to these people. You know, it is a law. It is a regulation. There is a lot of questions how that would be applied. But for your participation in these health information exchange networks if you are storing, compiling, transmitting, et cetera, you would be held to these standards. Again, that's the idea that we are discussing. All right. Any other comments from the Workgroup on our, I guess our starting hypothesis, before we turn to the sub-hypothesis.
>> Steve Bernstein:
Kirk, this is Steve Bernstein. Just a general comment. I think, I'm sensitive to the issue in terms of pushing this forward. I think even today, looking at the health information exchanges, looking at the other presenters, I'm not sure you really can easily come up with, and as a result I'm not sure you want to, a one size fits all. Because even the Massachusetts model is different than Rhode Island, that is different thanDelaware, that is different than RxHub. And I'm concerned there are so many nuances with the way these, I will say exchange organizations, for lack of a better term, are structured, that just sort of putting out sort of an omnibus, oh, just meet HIPAA, I worry about whether that actually works mechanically. There is hundreds of details. So I'm sensitive to that. So that's a general comment.
>> Kirk Nahra:
And it's a fair comment. It is a comment that we recognize and acknowledge to a point in the discussion about the relevant provisions of HIPAA. I also think that to the extent that there are particular points that you think would be a problem, we would love to hear about them. You know, your point is equally true about the people who are covered by HIPAA. There is a million variations, and that rule again, one of the things we have tried to do as a Workgroup is that we are not, at least yet, debating whether HIPAA is a good rule or not. And we are not debating all of the pieces. We may get to that. Our next step is going to be should we have a standard above HIPAA for this context? We are hoping to have that discussion be focused on, is there something different about this context that requires something more than HIPAA, rather than HIPAA is not a good rule. This group is not the place to say HIPAA is or is not a good rule. But we can evaluate whether HIPAA is a good idea, good set of principles for this kind of activity that's sort of the jurisdiction set of assignments for this Workgroup.
>> Steven Bernstein:
Right.
>> Kirk Nahra:
So
>> Steven Bernstein:
All right. Thank you.
>> Kirk Nahra:
Any other reactions from Workgroup members on the phone about the hypothesis?
>> Tom Wilder:
This is Tom Wilder with AHIP. I'm comfortable with the working hypothesis just as a starting point. I, you know, I think we need to think through in a little more detail what some of the words really mean, and we will probably do that in our discussion of some of the subs. I think where I'm, where I want to think further is on a number of points. The first one is what we mean by participate. I think we are talking about people who, as part of this network, have access to or grab on to identifiable health information. So that may be a subset of folks who actually are involved with the network. So I think we need to think through what participate really means.
>> Kirk Nahra:
Tom, is your concern that there are people who don't store, compile, transmit, or access but who do participate?
>> Tom Wilder:
Yes, and maybe that's not true. Maybe these are mythical people.
>> Kirk Nahra:
Well, I mean that's an important, that's an important, I mean, it is an important question. We try to have that phrase be broad enough to cover the different entities we have identified. Steve sent out today, and has sent out other times a sort of, a chart that had various categories. I mean, if there is someone missing, we would like to know, we would like to be able to identify them and probably deal with that through that, you know, the stored, compiled piece.
>> Tom Wilder:
Right.
>> Kirk Nahra:
But if there is anyone you can think of that, again, that we think is relevant who doesn't do, is relevant but doesn't do one of those things, we certainly want to deal with that.
>> Tom Wilder:
I think for me the issue is, we want to make sure we capture those people who gather, use, or disclose health information. We don't want to sweep in people that don't fall into that category. We don't want to miss people who, you know, might otherwise be in that category.
The other, I think this discussion about relevant HIPAA requirements is important. I think what we have heard from at least some of the people who testified today is that, and as you pointed out as well, HIPAA, not all the provisions are really applicable to everybody. So we need to kind of think through if there is certain pieces of that that may not be important. And then the final point I would make is, this whole discussion of at least equivalent to. And this is a path we may not want to go down. But I think at some point somebody has to have a discussion about, okay, do you have one single set of requirements that people follow or do you allow other, do you allow states, for example, as some states have done, to go further?
And there’s pro's and con's to that. But I think at some point we need to discuss whether or not we want to factor that into our analysis or if we want to, if that's one of those don't-go-there issues.
>> Kirk Nahra:
Yes. And I guess, my sense at a minimum, Tom, is that it is a not gothererightnow issue. I think there are other, I mean, I think for example this working hypothesis becomes, you know, I mean it is not clear what the next step is after that. But it is a significant statement. And I think it is a significant recognition of the variety of entities that are involved in this who are not the traditional healthcare entities that HIPAA does deal with.
I mean, you are raising a preemption issue, which I have personal views on, you know, and I talk about all the time in my professional life. But we have sort of dealt with that through the at least, right now at the at least point. We are clearly going to deal with it in terms of, you know, if everyone is up to a standard, we have already acknowledged we are going to talk about whether there is something in this environment that requires more than HIPAA. Maybe after that we go further. But I think that it is sort of, it is not until that point we get to the sort of national standard versus state variations.
>> Tom Wilder:
Right.
>> Kirk Nahra:
It is an issue we are all frankly, I was hearing it even more today. I mean, there was I guess it was Alison asked the question about the sort of state border issues and some of those things. I mean, I listen to what Massachusetts is doing and I think, boy, it is going to be hard to put some of those systems in place. One of the goals is to make sure that if I'm in California and I'm from Massachusetts, my information can get out there. It may be real hard to integrate all these states. We may end up with 50 versions of this instead of a national network. So I think that that state, you know, higher standard is a real issue but it is, I think it is down the road for us.
>> Tom Wilder:
Right.
>> Jodi Daniel:
Can I just ask a clarifying question, Tom. Your first point about participate. I'm wondering if it is a wording issue that doesn't make sense. Because it talks about participating in an electronic health information network through which information is stored, compiled, transmitted. Would it be helpful to flip that so that participate by being involved in the storage, compilation, transmission, or access of the information. Is there something there? Is what
>> Kirk Nahra:
I think there is two points. You are raising I think an appropriate wording question as to whether this sentence makes sense as it is. Tom's raising, I think, a somewhat different question
>> Jodi Daniel:
Okay.
>> Kirk Nahra:
which is, are those four categories broad enough to cover everybody?
>> Tom Wilder:
Yes, there is that. And there is also what does participate mean.
>> Kirk Nahra:
Well, I mean, maybe that's where Jodi is going. Because I think, the way she was going with that sentence, defines participate a little better by linking participate with those four concepts. We still have the issue of whether those four concepts are broad enough.
>> Tom Wilder:
I mean, I may be overanalyzing this. But the phone company may participate in this network because you are sending the information over the phone lines.
>> Kirk Nahra:
Well, but they transmit.
>> Tom Wilder:
Right.
>> Kirk Nahra:
So we are going to again, this statement I mean, you asked whether this was, whether there were companies that were missing from this. Now you are saying there may be companies that are covered that we don't want to cover.
>> Tom Wilder:
Yes.
>> Kirk Nahra:
But I'm not again, I'm not sure I agree with that.
>> Tom Wilder:
Right.
>> Kirk Nahra:
We can debate with RxHub about whether I was intrigued because I think a couple of people had a question about whether you're really a business associate or not. I think that's an interesting question.
>>
Well, and the other thing is I look at the words. I mean, I was using the word participate in the HIE in a very different context. I was talking about individuals agreeing to have their data shared through. And where you have got all persons, you know, does that mean, you know, if I am allowing my data to be shared as an individual, does that hold me to something about whether I can or cannot tell a family member? I -- only because I use, I actually use that term and we use that term a lot. And we mean something very different here than I think you are getting at.
>> Kirk Nahra:
Yes, very fair point. I don't think anyone envisions having a law that would say patients cannot market to themselves, or whatever the equivalent be. But I think we need to deal with that.
>>
It is the all persons part that I think
>> Kirk Nahra:
Well, the persons we want to we want to make sure that they are not all just businesses. It might be a doctor, it might be
>>
[inaudible]
>> Kirk Nahra:
For example, one of the categories that's not, I guess covered today is, there are lots of doctors who are not covered entities under HIPAA because of the way they bill. I mean, there may end up being none of those doctors who also participate in these regional networks. But it is a theoretical set today. So
>> Jodi Daniel:
Or you could have a researcher like an individual who is trying to access data through a network. So
>>
[inaudible]
>> Jodi Daniel:
Yes.
>>
The question of the word got me thinking
>> Kirk Nahra:
No one intends to bring those people
>>
Isn't some aspect of this the difference between a business associate and what was originally defined as a trading partner under HIPAA? Because there is a difference. For instance, the phone company might be considered a trading partner. And the whole HIPAA business associates component is not applicable, although there still are other requirements, like, for instance, some of the security aspects.
>> Kirk Nahra:
Yes. Well, let me do this. We are at the point of our schedule where we are running out of time. We need to do one thing just for our FACA purposes, which is open up the phone lines for any public comment. Judy, should we queue that up and come back in two minutes or okay. So we will be doing that in about two minutes. Let me try to summarize where I think we are, and then we will go from there.
You know, the next meeting of our Workgroup, I think we will continue this discussion a lot and try to move through both the main hypothesis and the subhypotheses. I would appreciate any Workgroup members that have particular reactions, suggestions, issues that they want to think about, wording, you know, any of that stuff, let's get them down on paper and let's get them into Steve over the next couple of days before people forget about them. It would be helpful to have that sooner rather than later. In general, I would like to encourage people to get their comments into us sooner so that we are not in a position of, you know, on the eve of a hearing, getting a lot of information we want to try to integrate. So let's get comments in on earlier drafts and earlier versions as much as we can. All right. Judy, why don't we queue up the
>> Judy Sparrow:
Want to bring in the public, please.
>> Jennifer Macellaro:
This is Jennifer. You have seen the slide up there for about a minute. It's got a number you can call in if you would like to make a comment and are not already dialed in. If you are already dialed in, you just need to press star 1 to ask a question. And there is an email address if anybody wants to write messages in after the meeting. So I will check back with you in a minute or two.
>> Judy Sparrow:
Do you want to talk about the June 9th [inaudible] changing the day?
>> Kirk Nahra:
Yes, we had a scheduling issue, I mean it was frankly my scheduling issue, with June 28th. So the proposal was June 19th. Is that so if people could check their calendars and, you know, let Steve know in the next couple of days if that doesn't work for you. Could we make sure to get something out because we have a number of people not on the phone, or not participating?
Let me do one other thing for the Workgroup members on the phone. When we took a roll call earlier, I think there were at least a couple of folks who were not part of the roll call. Alison joined, right? Alison, were you on the
>>
No.
>> Kirk Nahra:
She's not still on. She was on earlier. Is there anyone else who do not announce themselves as a Workgroup member earlier? Okay. I guess Alison was just the only one. Okay. Sue, did you
>> Susan McAndrew:
I think I
>> Kirk Nahra:
Okay. You are here though, okay.
>>
[inaudible]
>> Kirk Nahra:
All right. Can we go back to the phone lines?
>> Judy Sparrow:
Jennifer, did anyone dial in?
>> Jennifer Macellaro:
I don't have anybody dialing in today, no.
>> Judy Sparrow:
Okay. I think does anybody here want to make a comment?
>> Kirk Nahra:
Let me do one thing quickly, just for the Workgroup members. We have in the document that had the working hypothesis, we have a hypothesis and then three subhypotheses. In sub-hypothesis three, we had received a number of, some other options. And Jodi and Steve and I had gone through the different options. And our recommendation is that we work with option one, that's why it is called recommended.
Our concern about option two was that it seemed to give, the introductory clause, depending upon a given participant's role in the electronic Health Information Exchange network, we thought that gave sort of too much openended as to whether some people, you know, some people might not even have this law apply to them rather than focusing on the relevant issues. So we didn't think that was as effective.
And option three, again, seemed to be wordier and a little harder to follow than what we were trying to do in number one. But I would appreciate if people could take a look at those. Again, if you have any different views, please let us know. But that's sort of where we are going on the subhypotheses.
And again, any comments on these, I know these have been out for a little while. I don't know if people have had a chance to really go through it. But it would be, we really would like to try to move these through at the next meeting and maybe even get a signoff. So if there is word suggestions, word comments, we will be doing some of that here as well. But anything you have on that, any comments on that, please get them in at your earlier convenience.
>>
The next meeting [inaudible].
>>
Right.
>> Kirk Nahra:
Go ahead.
>> Jodi Daniel:
Yes. I guess, just in the two minutes on the planning for next meeting, clearly we are going to need to walk more through the hypothesis here, the working hypothesis and the subhypotheses, and try to nail those down. I'm wondering if it would be helpful to folks to bring in different types of entities than what we have had represented here today, probably fewer number, but to testify as well.
Steve had sent out a list of different categories of entities that may be non-covered entities that may -- under HIPAA -- but that may participate, depending on how we define that, in a health information exchange network. And wondering if that would be helpful to folks to kind of continue this dialog and try to bring in more entities of different types to come and testify, maybe just two or three.
>>
Jodi, I would say that that would probably be a real good idea given what we are trying to nail down are what are all of those bodies, of different possibilities that we want to make sure that we consider in this hypothesis. Because I think those different activities that we are struggling with that might define participate, the more we know who those people are and what the possible participation might be, the better we are going to be able to hit that in those defined activities.
>> Kirk Nahra:
I mean, I guess, and I think that's right. I also think that, I guess what I want to think about is whether we need testimony for that or whether you know, we have that chart. I guess I'm concerned, we could, I would like everyone to think about whether we need to have another testimony hearing in order to get that information, I guess. I think if we have another testimony hearing next time, we are probably postponing final review of this for another meeting after that. So let's think about that. I think it would be worth going through that list. Is that you have, is that in the meeting agenda or -- trying to remember.
>> Steve Posnack:
I sent it out previously. I mean, I think we have been refining our approach to collecting information over the past few meetings -- this is Steve by the way -- so if the intent of the Workgroup were to just have more people come and participate, you know, what I mentioned to the people that I had come and present today was that, you know, we dub them a Workgroup member for the day and kind of gain their insight over the course of the meeting rather than have them give a strict kind of testimony presentation. We can invite a couple more people in to participate in the conversation as subject matter experts that represent, you know, a genetic laboratory-type entity or something like that. And we can get their insight early but then, you know, focus more on the working hypothesis document towards the end of the meeting so we don't waste all the time kind of getting conversation.
>>
I have a question. You dub us the Workgroup members for the day. Considering this is an ongoing discussion for groups like us, do you want us on the next call or two until you think you have resolved this as continuing Workgroup members?
>> Kirk Nahra:
I think not.
>>
Okay.
>> Kirk Nahra:
Thank you for the offer. But we will what we will do is there may be, there may be things to reach out on particular questions. We may have some followups, but I think that was helpful for today.
>> Tony Trenkle:
My only comment is, and I confess I don't remember the list. I apologize. But if we are going to have people testify, push the envelope as to those who really may not come under, you know, covered entities. I mean, I think this group represents a group that, at least in my mind, is pretty clear. You know, so if we again, I have not seen the list. But I would push the list to get testimony from someone who today would say, geez, like the phone company. You know, I mean, wouldn't have the phone company come in and testify. But I mean, you know, push it to see if there is some people who would not be in the covered entity rather than a group that I think more clearly does fall within that bucket. That would be my only recommendation.
>> Kirk Nahra:
Yes, if people everybody take a look at the list. And I guess I would be interested in two issues. One is whether we think testimony would be useful and, if so, from which categories. I mean, there were 10 or 12 different categories on there. If we had I think we had two of the categories represented today. I don't know that we are going to bring in 10.
>>
[Inaudible] it seems to me the one may be next furthest out to the telephone company. Maybe some of the secondary users, the public health, the research people, and to what extent does their, I mean, how deep into the system, other than querying it, do you have to be to be a participant?
>>
Especially since it was raised today that several of the pilots are trying to keep secondary uses out of the initial approach.
>>
Yes, let me just clarify. It is by, more by demand than by desire, at least initially. So I'm glad you said initial because I don't think we see that as a desirable or longterm outcome, at least in my perspective. I actually think that would be a great suggestion.
>> Kirk Nahra:
All right. Well, again, if people have thoughts, let's send emails into Steve. He can combine them and get stuff out. Do you know the date offhand of the next meeting?
>> Steve Posnack:
May 17th will be our next meeting. 1:00.
>>
Everybody, let me extend a special thanks to our folks that testified today, both those of you who are in the room and traveled down here, as well as the folks on the phone. Appreciate that very much. It was very helpful. Thank you to our Workgroup members, and we are finished for the day. Thank you.