[This Transcript is Unedited]
Department of Health and Human Services
National Committee on Vital and Health Statistics
Subcommittee on Privacy, Confidentiality and Security
June 11, 2014
Hubert Humphrey Building
200 Independence Avenue, SW, Room 705-A
Washington, DC 20024
CONTENTS
- Subcommittee on Privacy, Confidentiality and Security Block – Leslie Francis, PhD and Linda Kloss, MA
P R O C E E D I N G S
MS. KLOSS: Good afternoon. Consider this the call to order of the Privacy, Confidentiality, and Security Subcommittee Meeting for June 11, 2014. We are working as a break out, but at the same time the committee of the whole.
As published, our agenda is tight, substantive this afternoon. We are already eight minutes late. We will move very quickly. Our main item of business this afternoon is to go through the design, goals, substance of the draft of the community data user toolkit and that is really most of our meeting. Then we are going to spend some time talking about where we go from here with this project of developing dynamic tools for community data users. Then we will have about a 20-minute discussion to follow up on the great introduction that Joy did this morning on data segmentation for privacy. Walter is going to share some work that he has done to summarize the status of standards and technology in this emerging area. And then we will talk about next steps.
Just as a reminder, our work plan for this year as a subcommittee is as you see items 1A and 1B really are following up on prior work that the subcommittee has done on stewardship, best practices, and our goal has been to really do the research, do some kind of workshop or other activity to advance best practices in the area of stewardship for community use and produce a report. Our plan would be to have come to the committee for approval at the September meeting. Our goal today is to review a draft so that we have the summer to get it into whatever is final shape, but we don’t ever think there will probably be final with this. But we will talk more about that later.
Our other work plan was to develop the privacy and security section of the HIPAA report. Happily, we stamp that completed.
And our third major goal for the year was to advise on other privacy issues, merging issues, outstanding HIPAA related issues, topic to be determined. That is really what we are taking up in data segmentation, not necessarily that that is the topic, but it certainly is an emerging area and we hope that coming out of that discussion will decide whether there is meaningful work that the subcommittee should do in this area or if there is another area. This is the open-ended more deliberative part of the meeting today. But as I said, the substance of today is to solicit your feedback on the draft toolkit.
With that, I will ask Leslie to introduce our learned contractor who has been terrific, Maureen Henry, who is at the computer and has been working with us for the past number of months.
DR. FRANCIS: Just very quickly about Maureen. She is a JD. She is a former director of the Governor’s Commission on Aging in Utah. Last year she was a politics and aging fellow in the Office of Senator John Warner from Virginia. We are very fortunate that she is finishing a PhD in nursing at Utah and was available to do some part-time work for us as a consultant. We will just turn it over to Maureen to get us through.
The idea of this, let me just say, is do not want to do any wordsmithing. We want to get some any ideas members of the committee have for things that either do not feel right, additions, things you think we ought to take out because there will be another draft. The goal is approval in September.
MS. MILAM: I just have a question. Our subcommittee call just last week went through this process. For the comments already shared, this is the same draft we are seeing that we have already worked through. Is that right?
MS. HENRY: Some of the changes from last week’s meeting were integrated, not all of them, given the tight timeframe between the meeting and when the materials for this came out. If you have given anything that is either a TBD or other comments from last week’s meeting then that will be coming.
MS. KLOSS: I just also want to thank Hetty Khan and Amy Chapper for helping us note take during this discussion.
MS. HENRY: And the other thing I will say about the proximity of last week’s subcommittee meeting and the materials for this meeting is that there were some last minute changes. And one that I saw today is that somehow in trying to fix the pages I eliminate them. If you do have comments then you can go by section name. That should get us close enough to where you are going, but my apologies if you are looking at a hard copy because the page numbers came off in those last minute changes.
PARTICIPANT: — probably looking at the PDF.
MS. HENRY: If you are looking at the PDF then you can just go by the numbers in the PDF pages that you are looking at this point. But if you are looking, as I see Jack is with a hard copy.
MS. KLOSS: The table of contents in the e-agenda book for this report is on page 103. It begins on 103.
MS. HENRY: I will start by going back to the beginning of what we are trying to do and the objectives. The objective of this project was to provide guidance for the use of data to improve community health. We began with an emphasis on privacy, confidentiality, and security, but the toolkit is not limited to privacy, confidentiality, and security because you cannot do a data stewardship toolkit without getting into some of the other areas like data integrity. It is not limited to that, but that is a primary focus of the document.
What came before the toolkit — there were three documents that have come out of past activities of the subcommittee. The most recent one was the joint roundtable on health data needs for community-driven change. The one prior to that was the stewardship framework letter that was sent to Secretary Sebelius in 2012. And prior to that was the community as a learning system using local data to improve local health. In order to come up with what went in to guide the drafting of the toolkit, one of the things that we did was we went back to these three documents and in particular looked at the recommendations from each of those reports as guidance on where we should go with this toolkit.
In addition to that, we did an environmental scan including the review of the past reports. On top of the review of the reports, I also spoke with about 20 people overall. That information was provided in the last full committee hearing materials where I talked to people about emerging issues in this area and what they saw as the most helpful pieces of what would go into a toolkit. There was both a culling process because initially it seemed too broad to deal with in a document like this. At the same time, there were some expansions, like I said, into things like data life cycle, which is not necessarily directly related to the privacy, confidentiality and security piece.
At the last full committee meeting, the charge that I walked away with and the subcommittee walked away with was to develop a community data user toolkit.
We spent a fair amount of time during some of the subcommittee meetings talking about the target audience. Communities generally are the target audience. Some examples of communities that we discussed were local government agencies, nonprofit organizations, and disease-specific groups.
At the same time, we have heard from subcommittee members that both further up in the government chain so potentially county level, potentially state level organizations might have an interest in this. But we directed it primarily at a less sophisticated user group. We are not directing this at directors of state public health departments. We are directing it more at an educated, but not necessarily very knowledgeable in the use of data to improve community health audience if that makes any sense.
What we tried to do is take a lot of this information from past hearings and filter it down to a point where it could provide a nice outline, but not necessarily all the detail that organizations would need to use community data.
The structure of the toolkit has changed a little bit over several drafts, but we are trying to frame it as we framed the data stewardship concept as outlined in the letter to the secretary in 2012. These are the subparts of that. Community and individual engagement and accountability, which the first two are both separate sections within a toolkit, but then in addition to that, they are addressed at every other section because to some degree both the engagement with individuals and communities and accountability needs to be accounted for throughout the other parts of the framework.
We have sections in addition to those two on purpose specification, data quality and integrity, data security, openness, transparency and choice and to protect de-identified data from re-identification. The structure within the document follows the framework in this section.
We have also addressed the data life cycle, again, for the purpose of highlighting to community data users that there is a life cycle to data that includes a number of different steps collecting, processing, analyzing, reporting, storing, destruction, repurposing, and then repurposed data would then cycle back into the system. We have addressed how that works. And the other thing that is addressed in the text of the report is assuring quality throughout the data lifecycle.
Under each one of the sections, we provided a brief explanation for the topic. In addition to that and this is not yet in there because this was something that was morphing right up until we turned the draft in for today’s meeting and that is how to use the case studies. And what was decided at the last meeting was that we would have narratives in one section at the back of the report, but then we would have blurbs from those narratives that illustrated the points that were made in each one of the sections throughout the toolkit. As I said, those are coming. That structure did not get decided until just before the materials for today came in.
And then for each section, we also are providing checklists that give the data users’ things to think about. Those are found at the end of each one of the sections.
We have identified some case studies, the ones that are listed on this slide and the ones that are in the document that you have today are the ones that we think illustrate a range of different issues across the data stewardship or the framework.
If any of you have examples of other case studies that you think would be helpful, please let us know because this does not have to be the final group of case studies that we are looking at. We were just talking over lunch today about how there may be closer to the community-level examples out there that we have not found based on who has testified in past meetings. We do not want to miss those if there are other examples that are out there that would be effective in demonstrating how this could work well or potentially not as well at the community level. In the emails and calls that I have made as part of the environmental scan, we ask both for successes and nonsuccesses. We did not really get many of the examples of the nonsuccesses. It may be that there are illustrations out there that should be identified that would give examples of how things have gone wrong in the past. Some of these are examples of that. For example, the Havasupai tribe biological sample is a good example on a larger scale of something going wrong.
PARTICIPANT: I think we should probably take questions or comments as we go.
DR. CARR: It is so exciting to this developing. It is great. Just building on the Datapalooza a week ago, there was an interesting app. I am trying to think of what it was called. But basically, they just took federal data and made it available I think in Chicago where you could go and find resources for domestic violence whereas if you just Googled — I was struck by the fact that very simple things can be transformative in the community. It was just cataloging thinking who is the user and what is it. I have the name here somewhere. It was Purple Folder.
The other thing is the title community data. Is it community data user or community data user?
MS. HENRY: I think that the way we thought about this is this is both. That it could be communities doing data collection locally. Some of these examples are like the Taking Neighborhood Health to Heart, which you may have heard from, the Denver project that was talked about in past meetings where they actually did original data collection within the community and with a lot of success at engaging the community in the process.
In other cases, it may be the eMERGE Network and what you are describing would be communities taking data from outside sources, sometimes local sources, local health departments, sometimes national sources like the CDC and using them targeted within the community. We are looking at both.
DR. CARR: You are right. Are there types? What is it that you want to show by the case studies because there are a lot of different things? If you had to say the overarching theme is I am looking for case studies that will demonstrate —
MS. HENRY: Both communities using data to promote health at the local level and that example with data sources coming from different places. Does that make sense?
MS. KLOSS: But with a bias to personally identify or more sensitive data with stewardship dimensions.
DR. FRANCIS: So the case studies. Some of them like Taking Neighborhood Health to Heart. The whole story is told. If you remember in the 2011 report, there were little digests at the end. But what we are going to have are boxes. We are talking about a particular aspect of stewardship. Say data integrity. There would be a little box that would describe how what a community did with respect to data integrity. A community that wants to either collect or use data can know what to think about and see how somebody else thought about this with respect to data integrity.
DR. CARR: It is privacy and confidentiality. What were those other things again?
MS. HENRY: It is all of the elements of the stewardship framework that we are looking at. Data integrity is one. The choice openness, engagement and choice. I am mixing them up. Community engagement. Different examples highlight different aspect of each piece of the stewardship framework.
PARTICIPANT: On the page 107 diagram.
DR. CARR: If you are looking for case studies, it is things —
PARTICIPANT: To illustrate those points.
MR. SOONTHORNSIMA: Those elements. But every case study does not have to exhibit all —
PARTICIPANT: No.
MS. HENRY: I think as we were viewing it, the Taking Neighborhood Health to Heart is nice because it does illustrate every step in the process. It is a tremendous example of a community-based, participatory research project where the community was engaged from conceptualization through analysis to disseminating results and then cycling back into the process. That one does illustrate every step in the process. I do not know that any of the others does to the same degree that that one does. That will be the most extensive case study. It will show up in many of the blocks. Some of the other ones will highlight examples that are pulled out of it, but would not necessarily show every step.
MS. MILAM: You are asking for idea of case studies. I think we had one day of privacy hearings with the community as a learning health system report. There was someone who testified from New York. It might have been the HIE. I think we later heard that there were issues with that consent process. Going back to that might be helpful. At the time that we heard the testimony, the issues had not arisen, but I think we heard later maybe through public reports that they had to reverse course.
PARTICIPANT: The Bronx project.
DR. MAYS: Part of what I am trying to understand in terms of the cases because there is a bunch of cases like telling us what would be helpful like where do you have a gap or something. We could dig up some cases, but I want to make sure it is what is unique. There are very few cases other than that that is going to cover all of them. Is it that you need something on the positive for which of the attributes?
MS. KLOSS: It is a good comment. I think maybe we should move on to the sections of the report because the way we are designing it now, the entire case study would come as appendices. We were doing that because at the joint roundtable, one of the recommendations made is let us see how others have done this. Let’s hear Chris’ comment and we will move on.
DR. FULCHER: I would like to spend some time talking with you about community comments. It is a public good utility where we have a lot of data, a lot of national source data, but abilities for integrating and uploading local and regional data. But as we worked with nonprofits and local government, et cetera, it is really as I have heard a couple people say it is through the narrative. It is the stories that we are telling where we have embedded the maps or the data as part of the stories. When you see what is going on in Chattanooga around food and food security or systems, you can then click on another community in the country with the same data coming up. How do you contextualize data local and regional and mixing it like you said maybe with federal data to tell the story? With cases, it is limited in some ways to just that area, but then how do we expand that to other communities around the country so it is meaningful in different areas?
MS. HENRY: The final section of the — next to last section of the report addresses regulatory and legal structures including HIPAA and human subjects’ protections. It is not meant to be in a comprehensive review of law that might apply to data use. It is not meant to imply that all health data is covered by HIPAA or that the human subjects’ protections through IRB and other similar academic models are the only way to go.
We did want to put it in there, one, because some of the data that people may want to access may be protected under HIPAA or may be the result of generation from a de-identified data set and therefore have some HIPAA implications. At the last meeting, we talked about how — this is one of the pieces that did not get into the draft. For example, HIPAA. It is important for people at the community level to understand what HIPAA does and does not require so that a community data user would be able to ask for the right things from people who have HIPAA protected data. We wanted to give people just at least a brief understanding of how they might be able to address the issue of HIPAA in trying to access data, for example, from health care providers or from an HIE.
The other reason to put the HIPAA and human subjects’ protections sections in the toolkit is that they are both the result of a lot of thought about how to protect privacy and about how to address these kinds of concerns. Even if they do not govern the specific use of the data, their illustrative of how one would go about protecting this kind of data when it is being used especially more sensitive data. And even when you are dealing with something like if it may not be HIPAA protected because it is de-identified that human subjects protections may go further in a university IRB setting because it might be more cognizant of risks of re-identification that are a little bit off the radar on the HIPAA side. We put some detailed information about these two systems into the report for those purposes and we will be pulling the threads back and tying that together more thoroughly in the next draft.
We also covered the issue of data use agreements. We have covered those again both in terms of how they might be required under HIPAA, but also because if a community is getting information, we wanted the community to have an understanding of what a data use agreement might do and how a data use agreement can help with the re-identification issue in terms of spelling out the requirements of a data user. We have gone into some detail about data use agreements. In the appendix, at the templates at the end, we will include both a sample notice of privacy practices as well as data use agreements.
Again, the notice of privacy practices is not intended to be limited to HIPAA, but to be used as an example of how community data users could let people know that their data may be used in one way or another. It is HIPAA serving as a template for other uses, not just a notice of privacy practices within the HIPAA context.
That is the overview of the toolkit as we framed it up to this point. I will give it back to you, Linda.
DR. FRANCIS: The current draft version is in your packets. It is fairly good size. There aren’t printed copies of it.
We are going to have a virtual reactor workshop, a couple of hours in July. To that, we are inviting everybody who has been involved in all the discussions Maureen has had, everybody who has testified at the prior NCVHS sessions that went into the generation of the toolkit. We are going to use that time to get feedback from the likely audience. If you have thoughts of people that would be good givers of feedback on this so we can invite them to participate on the 16th that would be super helpful at this point.
If you have had a chance to look at it, one of the goals of the way it is designed that Maureen has really worked hard on is to have it be very user friendly so that, for example, checklists. There are a lot of graphics in it, a lot of nice charts and things like that.
PARTICIPANT: I am going to bring it up and just scroll through it.
DR. MAYS: I agree with you. I think that it is very user friendly and it is pretty and things like that.
One of the things I was thinking about. I just do not know with the kind of federal entity. People often want these like roadmaps. I want to see a data user agreement and having one or two is okay. I am wondering if there is any way to either encourage people to deposit, to create along with your document a depository. And in the depository, you can then have people put in their data use agreement. What you have to do if you are doing genomics is going to be different than what you have to do if you are doing HIV, which is going to be different then. Some of them actually have laws that govern what you can and cannot do. To the extent that you could grow this where there is a depository, it would actually be I think great for people. I do not know then if you want ownership of it because then they could upload anything and everything. But the community usually is looking for a bunch of different type things.
DR. GREEN: A question and one suggestion. The question is what public health groups are going to show up at the July 16 workshop. State and territorial public health officers. I am talking about organizational level folks. The analogs of the industry for data standards for HIPAA transactions.
MS. KLOSS: We have a short list that we have developed through brainstorming. I will read off the folks. Debbie Main from Denver. David Kendrick, Tulsa.
DR. GREEN: These are people that are examples of people doing the work. I am talking about institutions.
MS. KLOSS: We are hopeful, aren’t we, that the network for public health law through Denise Chrysler will participate. But I know that we need to extend. If we do decide to invite her, we need to extend that invitation in the next week or so.
DR. GREEN: How about the American Public Health Association? That strikes me as being an opportunity not to miss. Some of the material that Walter circulated. The National Quality Forum today and yesterday or was it the day before yesterday and yesterday. They have a work group working on a toolkit for communities to use quality measures and stuff. The policy issue is suddenly the world is waking up to this. There are a lot of different folks that are working in this territory. It is perhaps an opportunity for us to do our convening role where we help people find each other and share.
To the other thing, just a list. A particularly potent group with deep and varied experiences called the High Plains Research Network that covers 18 counties in Eastern Colorado that involves every clinical practice, every hospital, and every emergency room that is overseen by a community governance group where the local folks are part of the governance about what they study, how they study, what data are needed and they have become very sophisticated. This is the group that PCORI modeled their recent small grants program to try to get community engagement going. They will bring a lot to the table. The contact there would be Jack Westfall.
MS. MILAM: Along those lines that Larry was suggesting, the American Health Lawyers Association has a fairly new public health law section. I think Gene Matthews — isn’t that right, Victor. Gene is the lead on that. He is a colleague of Denise’s. But American Health Lawyers would be great to have their representation of their public health law section separate from the network for public health law.
PARTICIPANT: What was his name?
MS. MILAM: Gene Matthews.
DR. MAYS: I think when Larry said this, it just reminded me that there are some groups that are actually all trying to do these community tools. Getting to those groups might be great. I am going to use one of Larry’s favorite, which is to go and send this to the CTSI network and ask them to send it to their actual community partners because they are really on the ground trying to do some of this and have collaborated.
The other group I would do the same thing with is called the Campus Community Partnerships because they are doing the same thing. They actually have partially a toolkit that you may want to look at. They have some agreements online about data user agreements. They would probably be a really big player.
And then this is where our federal partners come in, which is if you can get HRSA to send it to their community groups as well, HRSA and SAMHSA, I think you would be really covered at that point.
MS. KLOSS: I think we have some logistical questions. We do not fully know yet what our capacity is and those kinds of issues that we certainly need to nail down very soon.
DR. FRANCIS: One possibility that we are talking about is to have some ability to continue to update with samples and the data use agreement is a perfect example. If at HHS there could be a website where here are some communities. If you are thinking of data use agreements, here are some examples that people have been willing to share.
MS. KLOSS: As we looked at it last, we thought this should not be a static document, not in this day and age with as fast as everything is changing and that if there is any opportunity on the NCVHS website that this should be a more dynamic toolkit.
DR. CARR: Just a thought though. You then obligate yourself to make sure that everything that is up there is — having just done a similar thing on a different topic. You buy a lot of responsibility —
DR. MAYS: That is why I was suggesting a repository that somebody else like a community agency or something maintains for you.
DR. FULCHER: Also, the last two issues of the National Civic Review really highlighted the 25 years of the healthy communities movement effort. There are a number of organizations that have been involved in this. United Way, YMCA, other NGOs at the community level. I just would encourage the group to look at that as well because there is a lot of activity going on beside public health departments as well.
DR. GREEN: Another question. One of the spin off products of the IOM study that came out a year ago right now about integrating primary care and public health was this playbook. Does that hit you? Do you know what I am talking about? They did a press release that was here on six about a month ago. That has got traction. That is showing up all over the country right now. It has many of the same items in it.
Using that as an example, rather than see this as a competing community data user toolkit, it would be very nice to incorporate particularly the data stewardship idea. There are pieces of this that are missing from that conversation. There is an opportunity to expose this other work being done at NQF, this other work that is being at these other places.
DR. FRANCIS: One thing we could have is a resource page at the end.
DR. GREEN: — bridge too far, I think what we are really trying to create here is a movement. And to create movements, you have to build partnerships. You have to build coalitions and that sort of stuff. We can trade on our neutrality and our lack of conflicts of interest. We are not trying to promote a particular product. We are trying to get the right people to work together in the right place on the right problems in the right manner.
I suspect that the larger area we cast our net into it and welcome people to our, forgive me from being from the West, but to our campfire, maybe the fewer bonfires if people feel like we have just intruded into the turf that they have been in for the last 20 years and we did not have the courtesy to recognize it.
MS. KLOSS: Our approach to July. Now that we have made the decision to have it be virtually, it does not mean that that has to be the only one. We could give people two days. One in July and one in the fall. And just round up as much dialogue as we can about this.
DR. FRANCIS: We do want to bring it back to the full committee in September to wrap it up. If we do more than one day, I think we do one in July and one in August.
MS. KLOSS: Good ideas. Raj.
DR. CHANDERRAJ: Just ask a question. Are you using these data collection units to collect data or are you going to do something about it like treatment effectiveness of prediction of outcomes of the disease processes?
MS. KLOSS: No. Our goal is really to support communities that are using data for initiatives in their community, helping them to know how to maneuver through the data use challenges, but not the level of rigor that would be done in a research role of clinical effectiveness or uses of data at that much more rigorous level.
MS. HENRY: We make our recommendation at a number of junctures where we say if you want to do this, then you need to partner with someone who does have the experience and training and resources to achieve this. We are both trying to give people an intro, but then tell people the types of places they can go to partner in order to do things that if they want to get outside of that comfort area, then you need to bring others in.
MR. BURKE: To follow on that, that is where I thought the current structure is useful because it notes when you are outside of your wheelhouse and you need to talk to an IRB member or you need to talk to a privacy expert or you need to not keep going because everything you think you need is there.
DR. FULCHER: Very quick comment. As we work with so many communities, there is a different sense of what data means and what it actually is. Maybe bifurcating the use of the word data from very much population secondary level, publicly available data as oppose to the local and regional data that needs to be aggregated to a meaningful usable level like with HIPAA and all the privacy and security things. There are two different paths. So many people are just trying to get their heads around this publicly available secondary data introducing this second stream that is very clear separation would help people get their heads around that as well.
PARTICIPANT: That could be in the introduction.
MS. KLOSS: We have about five more minutes left on this topic. The wishes of the group please. Do you have substantive comments or questions on any of the sections or have we done enough to orient you to this and you can provide us with comments or suggestions based on your review or do you want to do a quick scroll through?
DR. FRANCIS: Or we could just pick one section and show people what it looks like if you haven’t had a chance to look at it.
MS. HENRY: Here is the beginning of the purpose specification part. It outlines what purpose specification is, some of the benefits of purpose specification. It then talks about the relationship. I know you cannot read this. I am sorry. It talks about the relationship between community engagement and purpose specification and how the two work together. It talks about the demands of purpose specification anticipating future uses, for example. More text on those topics. This is probably one of the most text heavy sections that there is.
One of the points that people are talking a little bit about the academic versus the community use and that is an issue that I think the more data is used at the community level, the more tensions are going to appear. One person mentioned in an email that the IRB requires disclosure of research results, which may be at odds with what communities want where they may want the information, but they may not want to publicize findings that are going to stigmatize groups within the community. This is an area that we just noted, but that is an area that I think is going to continue to get more attention.
And then at the end we have the checklist. It is not formatting quite right on this screen, but at the top of every section, who is the accountability entity or individual for this. What is the purpose of the data? What is the role of the community? What are the data elements needed to achieve purpose? And then it goes through. Is the data already available from a source so that people are not going off to collect new data that may already be available? Possible adverse consequences. Individual, privacy or confidentiality impacts, adverse impacts on the community or small group stigmatization. Plans to mitigate adverse consequences. Possible future use. Secondary analysis, repurposing, procedures for considering and limits on unplanned use of data and describe how to evaluate the need to consider additional consents.
One of the things that I think was the biggest challenge in putting this together is that nothing divides cleanly along section lines. The purpose specifications weaving in and out, the community engagement, the consent and notice issues, everything kind of weaves together. This demonstrates how that is done in this particular case. And then actually prior to this would be the blow out box talking about one or two of the case studies that help to illustrate the concept of purpose specification.
DR. FRANCIS: One reason for bringing this one up is that so often communities are using data drawn from other sources. Also, often other people may want to use or the community then may want to reuse data that they have collected. It is an area that has been an area of a lot of tension, not only the academic community, but also lots of questions about if you gather data to study this or to try to work on this problem and now you want to turn it to another problem, what is that going to do to the trust of the community if people are surprised?
MS. KLOSS: Any other comments? On the right track.
MR. SOONTHORNSIMA: As I glanced through all the sections, I think you have all the right sections and the elements are really well framed out. I wonder in the introduction if we couldn’t spend a bit more time why this document is important, to whom. It does a good job explaining about the toolkit and so forth. When you get into all the sections, it does a really good job without getting in too much detail. But that introduction has to be something that grabs you. You kind of said it earlier. It is not meant for everybody and you listed those entities. And what they can expect out of this, I think.
MS. KLOSS: Thank you, Maureen. I think you have done a yeoman’s job on a very difficult task. Thank you.
We will change gears quite dramatically at the other level of sophistication from community user to data segmentation. We have asked Walter who also is a member of the Privacy, Confidentiality and Security Subcommittee to continue our discussion. We have about 20 minutes for this.
DR. SUAREZ: Thank you. Well, I did not know of course that Joy was going to talk about this topic of data segmentation for privacy. It turned out to be actually very good because it gave a very good instruction of what I was going to try to cover.
I just wanted to highlight. Just some background. I am actually and have been involved in privacy and security for many years. I have been engaged in the Health IT Standards Committee and inside the Health IT Standards Committee co-chaired the Privacy and Security Workgroup, which looked at the standards for Privacy and Security. I have been monitoring really and participating in some of these initiatives that have happened in the Privacy and Security side. I am also a member of HL7 Security Work Group, which is one of the places where standards related to health information security are developed.
When Joy was talking about the data segmentation for privacy, that is why I stepped back and said when you look at all the spectrum of activities happening with respect and the latest development that are taking place with respect to privacy and security of health information, it is incredible what is going on. It is important to bring it back to this community to be aware of, not necessarily that we would take specific actions. We can discuss those at the end of this. But certainly, it is very important for us to be aware of all these developments that are happening and taking place from a technology perspective, more so than the policy perspective. There are policy developments, of course, with ONC’s framework for privacy and security. But on the technology side, there is an incredible amount of work.
This is just a brief highlight of the various things that I am going to talk about in three minutes each. You are going to pardon my speed. But just talk about data segmentation for privacy. You heard about a lot of it this morning. I am not going to spend a lot of time in it. There are behind it a lot of things done in the technology side to use electronic tags, if you will, little tags or little markers in the data that become really meta-data, data about the data, which describe some characteristics. There is a standard coding for those tags already developed and that is part of what this standard development process is.
There are also standards for coding and classifying confidentiality of information electronically, saying this information has the level of confidentiality. Tagging it electronically in a medical record. Not a lot of us probably knew about it or are necessarily familiar with it. There is coding to determine the sensitivity of that data in different levels and international standard for coding that.
There are other things like eConsent, a larger question that I had about eConsent. Data providence is a new initiative that is happening, and certainly NSTIC, National Strategy for Trusted Identifies in Cyberspace, which deals with more the identity of individuals in the electronic world. It is not just health care. It is industry, the entire global economy, if you will.
Some of the basic drivers very briefly. Sensitivity around privacy and information continues to grow. Exposures and breaches, we heard about them in health care and in other places. Higher expectations for patient engagement in care. Nothing about me without me is sort of the mode or the message. And when it comes to health information, it is more important.
Rapid adoption of EHRs. So certainly more information electronically is now available, collected, maintained. There are new requirements and expectations within meaningful use about the security of that information. Some of it. Expectations about what the EHRs need to do with respect to securing the data, but then also handling privacy.
Expanded demands for exchange of health information. Even within meaningful use, we are required to electronically exchange information with those providers using standards.
And then there is entire HIPAA privacy and security regulations that control really the process and the policies around disclosures and users of information.
And then really ultimately increase the expectations of patient controls over the health information. The what to access, by whom, for what purpose, when, how, all those questions. Some very basic definitions for everybody to be in the same page about this.
eConsent basically is conceptually being seen as the electronic mechanism to allow consumers to express privacy preferences regarding the collection maintenance, transfer access, use or disclosure of their health information. This is done electronically. Many about electronic health record systems and vendors in the electronic health record system world have modules, little modules inside the EHR. Some of them mostly refer to ROIs. You probably have heard of ROIs.
PARTICIPANT: Release of information.
DR. SUAREZ: It is an element inside the EHR already that reflects some of this concept of eConsent.
Data segmentation. We heard about it this morning as a process for sequestering. I think we were one of the first ones that use that word in our letter back in those days where it is sequestering and segmenting, those two processes. Capturing access view or disclosing certain data elements that are perceived by legal entities, institutional organizations or individuals being undesirable to be shared. That is segmentation and the concepts behind it. It is really a lot of the work that has been done to operationalize those concepts.
Meta data tags. You have heard that a lot. Meta data and the tags themselves. Key words or terms assigned to specific pieces of information about data that help describe a condition or characteristics of the data for purposes of further action that allow the electronic systems of a person to take further about the data.
Security labeling is actually something a little newer. It is a process for attaching meta data text to convey information used by systems to determine how to handle the data from a security perspective. They are used to handling things like access control. Someone is wanting to access internally within an organization. A physician wants to see a record for someone. Well, there might be security labels that require certain things before the data can be accessed even for a physician. There is that kind of security labeling. That is a very critical element across all these. This is the one that defines ultimately the tags.
And then providence. The latest addition, which is really something that actually has been mentioned and called in reference in other reports earlier. And probably one of the PCAST 2011 report was really a primary element of that report, the providence concept.
Attributes about the origin of health information at the time it was first created and attracts the users and the permutations of the health information over the life cycle of the health information. It is pervasive and persistent.
Here is a very quick picture of the security label concept. The security labels are really data pieces, little data pieces. This looks like a cell with some biologic elements in it more appropriately. They are used to clearly label information in order to facilitate human and computer handling of that information. It enables a computer to perform access control operations of the information so that information is accessed only by the appropriate and clear people in an appropriate location. It has different levels. We hard this morning from Joy that mostly it has been done at the document level. You heard that concept.
There are at least three levels that are considered right now. Document level section or segment level. Within the document, there are different sections. And then within sections, there are different data elements. Of course, at the data element level is the most challenging one to tag things because you can imagine tagging all sorts of data on a medical record, multiplicity of data elements about a person in a medical record and tagging each data element with a lot of information about what is happening with it. It could create a major disruption in the processing of the information.
We are starting, I think, at the document level as you heard this morning from Joy. That is the starting point, but it does not preclude the ability to do more in the tagging.
A lot of development at the standards development organizations that happen. You heard about the data segmentation for privacy. That was the focus of this morning. Just very briefly, this is actually the document prepared and developed by our HL7 security workgroup called the HL7 Version 3 Implementation Guide for data segmentation for privacy release one, which is tied to the CDA, the Clinical Document Architecture are released too, which is a standard as using meaningful use to exchange clinical information between providers. This ties to that standard and as the layer of data segmentation.
It is really the standard that allows electronic clinical documents in CDA form to be tagged at the document or in this case it does allow at the segment level is primarily being done at this point of the document level, with information that allowed the system to do things include the data from being accessed, used or disclosed. That is the segmentation part. And then be able to transmit the tags that are attached to the document, the security and privacy tags so that it can be informed to others. The next person that received the data. They see the data and then they see the tags that tell them some things about the data including some preferences of the consumer or some policy requirements like you cannot really disclose data under federal law according to CFR Part 2, for example.
This particular standard was, I think, mentioned by Joy. We went through one of the first times within the HL7 world. We go from developing the standard to jumping all the way to becoming a normative standard. Usually we go through several iterations including something called DSTU, Draft Standard for Trial Use, and we keep it there for a couple of years so that it can be used in a trial form as a standard before it gets normative. This jumped all the way to normative. We all accepted it and agreed to approve it that way. It is ready for adoption and implementation.
The standard there is ready. Nobody has mandated it yet to be used, and industry can adopt it voluntarily, is what is happening in some cases. Some organizations are beginning to use it. Others are waiting to see if it is going to be adopted in some law or regulation, for example, Meaningful Use Stage 3, and then become part of the expectation of an EHR. An EHR trial B, capable of handling data segmentation for privacy standards. That kind of situation.
But there are a lot of other things behind this and beyond data segmentation. One of the more critical ones was also published and developed by HL7 security work group called the International Standards for Healthcare Privacy and Security Classification, a new standard. It sort of uses what is called a Russian doll nested concept of going from document to segment to element level and binding security labels to certain data with some information. And the specific categories of the labels are things like the confidentiality classification of the data or the sensitivity, the providence of the data, and then a few others. Obligations, reframe policies, things like that.
These are the actual description of the security labels that are tied back to the data segmentation for privacy standards. A security label is referenced in the data segmentation for privacy because a secure label is the one that is used.
What are these labels? Everybody talks about these labels. Here are a few examples. I know this is going to be very hard to read. Here are the confidentiality labels that are being used right now. This is standards. This is now official international standards. On this side, you can see very restrictive, restrictive, normal, moderate, low and restricted. Now the first question everybody is having probably is where is the definition of each of these elements. Who decides what is what? Well, there is a definition and who decides what is what is the person that tags this with that record. Someone could say this for me is normal, but someone else might say this is very restrictive for me. Depending on the internal policies of the organization, depending on the external policies imposed on the organization, and depending on if this is a consumer choice, depending on the consumer preferences.
You can see the sensitivity tags. There is already HIV, Sickle cell, VIP, person that is classified as VIP, we all are, right? Substance abuse, mental health, genetic. There are a number of other sensitivity tags. There are providence tags also. Clinician reported, professional reported. Each of these has already been defined as tags to be used in connection with the data segmentation and the providence process. All this is in place. Nothing is final. Of course, this is evolving. And as we find that, we need more and better and improved ways to define these tags and to add new tags then there is a process. That is part of the standard development and maintenance process that is used.
There is a couple of other tagging. Purpose of use. A lot of in the US mostly and by the way, this is a lot in the US. A lot of other countries are following what we are doing, but they do not have the complexity that we have of restrictive and controlling access and use and disclosure of data by things like purpose of use, treatment, payment operations, and other things. You can see here the purpose of use include those kinds of classifications.
Obligation tags include these types of things. When I send you this data, I am by agreement with you as recipient of the data enforcing and requiring you as an obligation to encrypt the data if you are going to maintain it or if you are going to forward it or continue it. There are minimum necessary mask reactants, a number of these obligations with respect to the data.
It is both applicable to the entity that has the data. If I have the data and this data has these tags, I know that this data has to be encrypted that I have to consider minimum necessary before I can use it or disclose it. I might need to mask it. That is part of the segmentation. I need to do all these other things. Very exciting and interesting and innovative stuff really happening around this.
DR. CARR: At the risk of being a broken record, I think that the progress that has been made in segmentation is very elegant. I wonder. Are we looking at the end product that let’s say if it is exchanging electronic health information among providers? What is the impact on care delivery when elements are sequestered and that that sequestration may or may not be known to the provider? That is not to say that patients do not sequester information of their own giving of the narrative. But I guess the more elegant we get in the segmentation, I think we should be always looking at and the end product with this will now look like that. And make sure that the end product is going to be usable to the very people who need it to do —
DR. SUAREZ: Absolutely. This is the point that we did not get to ask Joy or to talk about with Joy because when you hear this capability, what this is meaning is that an EHR in the future is going to be capable of allowing the entity that maintains that EHR to mark and tag certain things before it gets out. Now, when would I as an entity, an organization decide to do that? Well, there is going to be two sources, I think, or more probably, but two at least that I can think of. One is an external policy directive that makes me tag things. In general, right now, there is only one major one in this country. If you are a behavior health provider subject to 42 CFR Part 2, you have to do this. Now, you are doing it today. Everybody is doing it today in different ways. In paper, we are redacting.
Before we send out a record, we have to follow 42 CFR Part 2. Now this is allowing us to do it electronically as well. That is the only external, enforceable requirement. Anything else is chosen by me. I might not decide to do this as an internal policy to offer the consumer the capability of segmenting any and every type of data they have. Right now, I only require to do it for one thing 42 CFR Part 2. Everything else is decided by the organization. The organization can shut down everything else.
DR. CARR: There is state law also.
DR. SUAREZ: The state laws require consent, but they do not require segmentation. It is very different.
DR. CARR: Is there a group that keeps working in parallel with here is what we can do and here is what the impact will be? It just seems like there is a lot of resources on segmenting. I just do not know who the group is that is saying what have you done to my medical record.
DR. SUAREZ: There is going to be probably a lot of analysis about the impact of extending the use of the segmentation to areas beyond 42 CFR Part 2. 42 CFR Part 2 is the one about substance abuse. If I am a substance abuse provider, I am going to have to do this. Beyond that, there is going to be a lot of questions about what if I am doing this for other things beyond 42 CFR Part 2. HIV. I do not want my data to be shown to my cardiologist that I have HIV. As under HIPAA, right now a consumer has the right to request a limitation of disclosures. But they do not have the right authority or the ability to say I want this to be segmented. They have the right to request. I would like not to disclose this, but the provider can say we believe that this is integral to the care and the cardiologist needs to know that you have HIV. We are not going to acknowledge that.
DR. WALKER: Walter, to ask Justine’s question in slightly different language, one of the fundamental tenets of safety engineering is that when you design a process that has obvious potential for adverse effects, you do FMEA or perspective risk assessment, different methodologies to try to anticipate what those might be so that you can design the system to decrease their likelihood or at least capture them for review. Has anyone done anything like this for segmentation?
DR. SUAREZ: No. And really what we are finding is that in some ways technology is pushing the — this is responding specifically to one request and requirement. What you did not hear was that the main supporter of this initiative was SAMHSA and HHS, the Substance Abuse and Mental Health Administration. SAMHSA was the one that put — because SAMHSA needed to administer this process.
DR. WALKER: My point is that there will be adverse effects and we will all pretend to be surprised. It is sort of why we do not encrypt laptops. It is not a secret that you should do a perspective risk assessment. We just do not do it. It is too expensive, too hard, too something or other.
DR. SUAREZ: My point was going to be basically in this case technology by virtue of fulfilling one specific requirement is opening the door for policy to be now added. Technology in some ways is driving —
DR. WALKER: My point is that SAMHSA should have done a PRA and my guess is that they did not —
DR. SUAREZ: We probably need to do that or consider moving in that direction through other groups.
DR. CARR: You made an important point though. Segmentation and consent are two different things, but they are getting blended. I think that is the slippery slope.
MS. GOSS: And not only is segmentation separate from the consent, to your point, Justine, about what somebody sees at the end has a huge implication on somebody who interprets the response that they get in a health information exchange activity. Walter tried to go down this path when he has talked about policy when we start looking at the technology driving a solution capability, but how it is going to get implemented and how it is going to translate into a vendor product that is going to impact how a clinician interprets the presence or lack thereof of data is a huge question.
MS. KLOSS: Larry, Ob, Leslie and then we will roll.
DR. GREEN: I wanted to ask you guys to connect this up to the toolkit. This sort of information. Is it going to be accessible through the toolkit?
MS. KLOSS: No. This is kind of way the other end.
DR. GREEN: I want to declare this a devil’s advocacy position. I do not want you to do this. That is not what I am trying to say. But the more advanced communities want to know this and they cannot get to it. They do not know how to get to this. Walter started us off with definitions. Take that all the way to Justine’s comment about there is a difference between data segmentation and consent. This discussion going on right now is I believe the bleeding cutting edge of where this nation’s communities are in trying to create this integration of clinical data, administrative data, and community data from all over the place. There are just not very many people that can even identify what the issues are that they need to know about. We are over a target here. I take your point. This is not what the toolkit is about. What comes next? We may be seeing it forecast right here right now. By fall, we may want to be coming back to this territory.
MS. KLOSS: That is why we wanted to probe in this area and see what the implications were.
MR. SOONTHORNSIMA: I agree that consent and segmentation are two different things. However, this is a question. Does that make consent — the capability here makes consent even more granular, thus, the danger of people holding even closer to HHS, let alone able to understand what the heck this is, therefore, making them even more.
DR. SUAREZ: Briefly to mention this. That is why when Joy was presenting it, I mentioned it. Data segmentation in many respects is a component of and a working element of eConsent and consent in general because it is tied to it and a way of executing an aspect of consent. Now, the question that you bring up is do I have to include segmentation in every consent. In other words, am I required by something that says eConsent has to be granular enough to allow me to do segmentation? The answer is no. The answer is only there is so far one specific requirement in the federal law that pushes for a segmentation expectation.
MR. SOONTHORNSIMA: My point is not now, not yet. That is a danger. I am just raising that. The capabilities are there.
DR. SUAREZ: Technology is offering that ability to say to policymakers and to policy developers. You have now the ability to push it harder. That is the key.
DR. FRANCIS: I wanted to just comment that I have been part as our liaison to the tiger team I have been part of some of these discussions. One thing I think is really important is that segmentation is about separate management possibilities. It is not necessarily about suppression.
What is currently happening is and this is the SAMHSA example is that a SAMSHA provider because you cannot then retransfer without — it is not transferring the data at all. The record is not getting the behavioral health or substance abuse treatment information. Now what data segmentation lets you do is put a tag on that when you send it and lots of questions about what the characteristics would be of the document that you send. But once you send it, it enables you to tag it to say this cannot be retransferred without going back then to the relevant SAMHSA permissions. Certainly, it opens doors for other kinds of uses, but the initial use or the initial reason for having this is to allow sharing of information that without segmentation was not being shared at all.
DR. SUAREZ: There are two sides of this. One is allowing the inclusion of something that — because I could not separate. Now I can separate and send only that and tag it until the other person does not disclose it until you comply. The other one is my internal system being able to really exclude some things and be able to disclose the others that I can disclose without any control, without having to have any consent.
MS. KLOSS: Vickie, you were next. Sallie and Justine. We are kind of bumping up against the end of our privacy, confidentiality and security time here. Unless we want to spill into standards, which we kind of are.
DR. MAYS: I want to pick up where Larry was going. As you were presenting, I could see parts and that was going to be my recommendation. I could see part of things that I thought should be a part of the toolkit. For example, when he was doing the definitions, I would not call it that in the toolkit. I would just say some concepts for consideration.
Part of what that does is it helps us to bring the community along with some of these complex issues. Some of it has to be rewritten a bit. But I think putting that in there allows them to know how to ask about it. They will ask about these things relative to their own data. They will ask about the things when participating. And then they will ask about it when they receive data. I think we are doing a contribution to do that.
Then there was another point when he was talking. This is where we need some cases to kind of give them an example of how these things happen both for the good and sometimes for the bad. While you have those cases attached to the other sections explaining those concepts, I thought some of the cases with the way in which he was explaining electronic health records and things like that would have been perfect. I really think what Walter has really can be, lack of a better term, dumbed down a little bit more so that it is kind of common language, but it is very educational language. I really hope that we can get some of that into it.
DR. SUAREZ: I would argue this next part that the data providence is even more so.
PARTICIPANT: Where did the data come from?
MS. MILAM: I have two questions for you, Walter, Before SAMHSA undertook this initiative with data segmentation, and did they hold any listening sessions or hearings to see if the notice requirements and the consent requirements were still needed today? Were those validated from consumers? The notice that has to accompany every disclosure Part 2 data and the special consent requirement for any onward transfer. Do you know if they reached out to consumers, to patients or to providers to see if it —
DR. SUAREZ: I was not aware or I am not aware, but I am sure that they have reached out quite a bit and not just consumers, but providers that are part of Part 2 before even doing this whole process. This is their big initiative from a health IT perspective. I am sure they did it, but I am not familiar with them. I know that they had a lot of background and a lot of work done in preparation for moving this forward.
MS. MILAM: Second question. Who applies the tags to the data?
DR. SUAREZ: The expectation is that the EHR will have the capability to through screens allow the user of that EHR. In this case, the provider, or whoever. The provider could be the physician, the nurse, whomever responsible, the record person to actually do the tagging. Some of the tagging is automatically then based on pre-classification of data. Some of the tagging has to be manually done because of the system not being able to recognize that this data is sensitive. There are ways that the systems can recognize that this data is Part 2 type data. There are mechanisms in the EHR that allow to do that. There are some other types of data and some other types of systems where manually someone has to really mark it. The EHRs would have those types of capabilities to do either — basically, the automatic tagging as well as the manual tag. But it will be the EHR entity or individual responsible for that. It would not be the patient.
PARTICIPANT: It would be health care policy.
DR. CARR: Today as part of meaningful use two in the absence of the HL7, it is required that discharge CCD be send to the primary care physician. This seems asynchronous to me because it automatically gets sent to the PCP who is not the substance abuse physician. There is no segmenting. This seems to be an example of asynchrony where we are on the one hand pushing data to a person that I don’t know if I understand the law correctly, but I am not sure that PCP is an automatic person to get the substance data. But that is required by meaning use may be contradictory to the law. And we do not have the technology in place to manage it once that CCD is going there. I am just pointing out that as an example of an intersection of where this asynchrony creates mischief.
DR. SUAREZ: That is a reality for providers that are meaningful users and that are behavioral health providers classifying their part two. That if they are going to disclose the data and going to use that for meaningful use meeting requirement purposes then they have to disclose it in the appropriate way. Now today there is no tagging in their systems yet.
DR. CARR: Vendors have built systems that automatically push the data. No vendor has created any kind of —
DR. SUAREZ: Very quickly to finish up if I can. The good thing is the Standards Committee is probably going to be able to give you some time because we do not have a report to review anymore. We approve them. Let me finish up.
Data providence is the other big project that is happening. It is separate from eConsent and segmentation. Data providence really focuses on the question of tagging something to inform the source. It was, as I mentioned, highlighted as a priority action in the 2011 PCAST report. It uses similar meta data tagging concepts as the data segmentation at various levels, document levels for providence data levels, section level. Various factors are tagged. Basically, who was the author in terms of the individual, the entity, the system source, the daytime stamp, a lot of other things. And really the intent is to pursue or to convey with confidence to the recipient the authenticity, reliability, and trustworthiness of the information being exchanged so that that person can have a clear way of understanding who is the source, what is the source, and what is the trail of the providence to validate and decide whether they rely on the data for use or not.
What is happening with data providence? We had the PCAST report. Everybody wanted to move in that direction. There are some elements of data providence already built into things like the CCD or the CDA. In the CDA when you send a document from an EHR to another, the header of the CDA, the header of the electronic document has some providence in it. It is already covered, but it is not necessarily consistently used. It is not necessarily complete. There are a number of questions. There was a need really to create a formal initiative to push forward with this. That is what happened about two months ago literally. This is very new within the Office of the National Coordinators Standards on Interoperability Framework, S&I framework. A new initiative was created called data providence.
The issue that we are trying to address was that nonexistence of authoritative specification or standard or model was providence in health information. And the goals of the initiative are to really establish some guidance for handling data providence in content standard, establish the minimum set of providence data elements that need to be included and the coding vocabulary being used, and standardize the providence capabilities to enable interoperability. Really, with the goal of defining those standards so that they can also be included in EHR requirements in the future.
The phases of this project. Right now, the phase one has been completed as to a week ago. The consensus on the charter and scope of this initiative. The phase to adjust started, which is the identification and definition of the use cases. Phase three will be the use case harmonization and identification of standard. What are the standards that exist, how mature they are, what is the status of those standards? Then we go into pilots and then evaluations of those. At the end of the day, the outcomes will be a set of implementation guidelines, best practices, models, but more importantly perhaps a set of standard artifacts, basically a set of standards that will be then sent back to one of the standard development organizations because the framework is not a standard development organization. Any products they produce has to come to one of the SEOs like HL7 or IHE or someone else to vet them as a standard and then adopt officially as this is the international standard for coding data providence. That is at the end of the cycle. I think this is going to take about six months before we can see some of that.
The last topic is NSTIC. I am going to probably skip the NSTIC, basically the strategy to allow a new identity echo system to be developed. There is a lot of work being done for NSTIC. It has been three years since they started. Things have been piloted. There was an NSTIC meeting earlier this year to demonstrate the pilots. A lot of the pilots actually like half of the pilots were for health care in the health care industry. This is not health care. This is for every segment of the economy really. But a lot of them were pilots related to health care.
And really, the goal here is to identify a mechanism to do what we normally do with respect to identity management. You all have heard of PKI, the public key infrastructure and the concepts of two-factor authentication and all those elements. This is trying to create a now defined, formalized mechanism to identify across the board anybody.
The initiative started within the federal government saying if I am a consumer, I go to one federal agency. Identify to them in one way with two-factor authentication. It is not just my log in and pathway. I have to have something that I am, that I know, that I represent. I have to do a biometric or some other key or some other thing. But then if I go to another agency, I have to do a different thing. Why not have a common one that they can cross certify and validate. That is the entire concept of forming an echo system that then can be extended beyond the federal government. Health care is very into this because there are a lot of identity issues. The identity of the physicians and the providers when they send data across states for emergencies or things like that — the patients of course and other participants. There is a lot more work to be done in this. I just wanted you all to be aware of it.
Putting it all together. This is my last slide. Participants in a transaction, for example, and information exchange including patient providers uniquely identified through an NSTIC mechanism. This is kind of bringing all those pieces together. The organization defines as privacy and security policies based on external policy requirements and internal organizational policies. Consumers then set preference of some sort of eConsent that allow the consumer to say yes, I authorize this generally. And open eConsent or have some more granular consent options.
The security tag behind the scenes are capturing that information and then automatically tagging different data elements inside or different data parts inside the information of the patient, the electronic record of the patient. Defining the confidentiality, sensitivity, integrity, providence, purpose of use codes.
And then whenever the data needs to be accessed or used or disclosed, all those tags are now playing into how a person can access it or use it or the data can be then put together into a record that can be disclosed or segmented and not be disclosed.
And then the important part of the tags are attached to that information that goes out. Now as I asked Joy this morning, there are two parts of this. One is the tag might be something about a federal law that applies regardless of jurisdiction. 42 CFR Part 2. It does not matter which state I am. The recipient of that even if it is in another state across the country they have to comply with 42 CFR Part 2 as well.
But if I am in California and I need to give consent before disclosing HIV data or I have to get consent and then I am able to get that data. And I send that HIV result to someone in Arizona and I tag the data saying there is a consent required element. It is a consent required element in California. In Arizona, they might have a law that says you can disclose it without consent. That creates a break in the tags that have to be analyzed. And the organization has to take the tags and determining whether the state law that allowed or not are required and their internal policy.
It is very dynamic and I think we are just at the verge of really getting this moving. Most of these consents are currently being developed literally. You saw the approval of the actual data segmentation for privacy. The date, if you noticed, was May 2014, about 15 days ago. This is literally happening right now.
The national and international standards are being created. A lot of people are paying attention to what we are doing because a lot of people in other countries want to see how this is done.
At least one organization has begun to implement a lot of this. The VA. The VA is very advanced in terms of meta data tagging, segmentation, and having agreement with others to rely upon those data tags.
But as I said, no federal state policy currently exists or require all these data elements to be put in place. One specific requirement. 42 CFR Part 2 for substance abuse.
It is expected that for phase three of meaningful use, which starts in 2017, some of these concepts will be incorporated. The expectation that EHRs are going to be capable of handling data segmentation tags and data providence tags and things like that. We expect that that is going to be happening.
I do not know that on the meaningful use requirement side. There are two parts of meaning use. The standards that are adopted and the certification program. And then what we need to do as meaningful users. We have to do 80 percent of our exchanges doing this. I do not know if they might put some requirement that says 80 percent of your disclosures have to have a tag. I do not think that is going to work. I hope it is not going to go that way. But at least in the standards, there will be a requirement that if you are going to certify as an EHR, if you are going to get a certification that you are an EHR-certified system, you are going to have to meet this. I expect that that will happen. That is my last slide.
MR. SOONTHORNSIMA: I just have one quick question. It is interesting about the slide about NSTIC. That is not to be confused with patient identify.
DR. SUAREZ: On the contrary, this is an ability for the consumer to be identified without being identified. In other words, to be identified with a code, with a mechanism that allows them to do business without disclosing who they are in reality in terms of the actual person specifically. It is an echo system that allows the unique identification of the participants in a protected way.
MS. KLOSS: That was great.
DR. SUAREZ: I will make this available to the committee members and the slides.
MS. KLOSS: Our purpose here was just to do an overview and chew on what it might mean for us. I certainly I think it catapults to a new level of thinking about what privacy and confidentiality and security is going to mean in a very short timeframe.
I think with that, we are adjourned. Thank you so much for feedback. Now, let’s go to Standards.
(Subcommittee adjourned.)