What's Next for Tiger Team?Input on Privacy, Security Issues Sought
Until now, the team's recommendations to the Office of the National Coordinator for Health IT generally have dealt with privacy and security issues related to "push" transactions, such as when a primary care physician transmits patient data to a specialist. Next, the team will consider the security steps needed when, for example, a doctor makes a query to find all available records from multiple sources for a patient being treated in an emergency room.
In an interview (transcript below) with Howard Anderson, executive editor at HealthcareInfoSecurity.com, McGraw says the team also eventually will address privacy and security issues involved in the secondary use of patient data, such as for research.
From the beginning, the team has considered the fair information practice principles that the ONC developed in 2008, reviewed what HIPAA already requires, and then identified "what the gaps are in both policies and best practices," she says. "Now, we'd love to get input from the public about where the gaps are and where we should go from here."
The team is accepting suggestions on its blog, which offers a detailed guide to the fair information practice principles, relevant HIPAA provisions as well as the recommendations the tiger team has made so far.
In the latest in a series of interviews with HealthcareInfoSecurity.com, McGraw also:
- Explains why the team recommended that the Stage 2 criteria for the HITECH Act electronic health record incentive program should require participants to verify how stored data is being kept secure.
- Explains why the team stopped short of endorsing a mandate for the use of encryption.
- Says she personally supports requiring encryption in certain circumstances, such as for mobile devices. "I do personally think that the healthcare industry is a little bit behind where other sectors are with respect to robust use of encryption to protect data," she says.
- Describes the team's other recommendations that the Health IT Policy Committee approved at its last meeting (See: Privacy, Security Proposals Advance). For example, the team endorsed two-factor authentication for remote access to EHRs as well as the creation of standard formats for data fields used to match patients to the right records.
An attorney, McGraw is director of the health privacy project at the Center for Democracy & Technology.
HOWARD ANDERSON: The Health IT Policy Committee recently accepted a long list of tiger team recommendations. For example, the team recommended the electronic health record incentive program require participants to verify how stored data is being kept secure, such as through encryption. Please explain this requirement, and tell us why the team thought it was important.
DEVEN MCGRAW: Well the requirement really isn't any more strenuous than what the HIPAA security rule already requires, which is that covered entities have to address how they're keeping stored data secure, including whether or not they're going to implement encryption in order to do that. We thought it was important to lift this up within a range of security issues that providers have to attend to because of the number of breaches that have occurred that involve theft or loss of stored data that's not encrypted. Certified EHRs [that are eligible for the incentive program] have to have encryption functionality in them, but clearly there are entities that are just not using it. And we really wanted to underscore that requirement as part of the meaningful use program.
The Encryption IssueANDERSON: Encryption of data at rest as well as data in motion is an addressable requirement in the HIPAA security rule, as you just mentioned. That means that if an organization determines that encryption is not reasonable and appropriate they can choose to document another equally reasonable method of protection. The tiger team didn't call for changing HIPAA to include an encryption mandate; instead it called attention to the need to comply with the HIPAA security rule guidelines for protect stored data. So why did you take that approach, and would you eventually like to see encryption of data in motion and data at rest explicitly mandated under HIPAA in some or all circumstances?
MCGRAW: The reason why we took the approach of just underscoring what HIPAA already requires, rather than suggesting or recommending that it go further and absolutely require encryption, is that we were advised by some of the members of the tiger team who actually do work on security within covered entities ... that while encryption is an important tool, there are circumstances under which if you use it, it creates some downsides with respect to data access and data flows that ... would be unacceptable. ... So I don't think we would have gotten to consensus on a requirement that encryption of data at rest is required in all circumstances.
Now having said that, I do personally think that the healthcare industry is a little bit behind where other sectors are with respect to robust use of encryption to protect data, and we really do need to be pushing a little bit further here in circumstances where there is a clear case for encryption and not really any good viable reason why it wouldn't be used. Mobile devices, for example, is one area where at least we at Center for Democracy & Technology have called for an encryption mandate. I think when the law is clear on those issues, you get some more consistent implementation across the board.
Privacy, Security ProvisionsANDERSON: Please summarize the other privacy and security provisions recommended by the tiger team and approved by the HIT policy committee April 13 that could wind up being included as stage 2 requirements for the EHR incentive program or as part of other regulations.
MCGRAW: ... The common theme is that the recommendations have a link to technical functionalities that may need to be present in the stage 2 [EHR software] certification requirements. We put forward some recommendations on authentication of provider users of electronic health records and said that with respect to remote access, there ought to be more than one factor, in other words, more than just a user name and a password. And the certified systems are going to have to be able to accommodate the use of two-factor authentication, per the recently released Drug Enforcement Administration rules, when controlled substances are being prescribed through e-prescribing. So we took care of that issue.
We also looked at the patient portal issue, which is being considered by the Meaningful Use Workgroup as a potential requirement in Stage 2. We said that with respect to identification and authentication of patient portal users, a baseline of at least a user name and password would be required; certainly entities are permitted to go beyond that and require additional factors, such as knowledge-based tokens or actual tokens. But we cautioned here ... you want to make sure that you're not setting the bar so high that you're discouraging people from using the systems.
And then in the third area, we took a look at our recommendations that we had teed up earlier for patient matching and reminded the Health IT Policy Committee that it needed to send some explicit instructions to the Health IT Standards Committee for the demographic data fields that need to be present and what's the standard for when data is missing in a certain field, like when you don't know an address for an emergency patient who is not conscious. So those were some of the recommendations. ...
AuthenticationANDERSON: The tiger team also recommended the use of two-factor authentication for organizations that eventually will use the Nationwide Health Information Network Standards when exchanging data. Explain the reasons behind that. And will that recommendation likely be included in the pending Nationwide Health Information Network governance rule?
MCGRAW: Well the reasons behind requiring two-factor authentication for remote access is that access through the Internet or some other unsecure network is obviously a place of vulnerability from a security standpoint. So we thought that a simple user name and password should not really be enough.
This was the second time these recommendations had come before the policy committee, because we had used the previous meeting in March to get some feedback from the committee because we weren't quite ready to dry the ink on the recommendations. At that point, the national coordinator for health IT, David Blumenthal [since replaced by Farzad Mostashari], invited us to go down the road of suggesting that a requirement for participation in the Nationwide Health Information Network include these more robust authentication criteria ... Given that it appeared that the office of the national coordinator was thinking in that direction, we have a pretty good chance of seeing these requirements in the governance rule.
Patient MatchingANDERSON: The team also called for the creation of standard formats for data fields used to match patients to the right records, as you mentioned earlier. Can you explain how that would help protect privacy and how might regulators initially carry out those standards?
MCGRAW: ... A lot of people don't think about this as a privacy issue. But ... if a ... hospital or a doctor's office opens up the wrong record because they haven't matched the data in the record to the right patient, that's obviously potentially a breach of the person's record. And then if there's incorrect data that ends up in your record, or duplicate records because they can't match the records to you, it's both a privacy and a security issue and a potential quality of care issue. ... We had an entire hearing on this patient matching issue. It's a technology issue and it involves making sure that the data is inputted right in the first place. ... There are so many human factors involved in it, and a strong role for patients to play in checking that the data in the record is, in fact, theirs ... We had a whole series of recommendations that dealt with both the human factors and the technology factors. In the case of the technology, obviously, if people are using standard data field formats and representing missing data in its consistent standardized way, then, as the records are exchanged, there's a greater likelihood of getting a more accurate patient match.
ANDERSON: And how might those standard formats be incorporated in a regulation?
MCGRAW: Well the place where we foresee them initially being put out into the market would be through EHR certification standards [for the incentive program]. The EHRs would present the data fields in the right format and recognize the standard for missing data. ... Now it's a little bit trickier from a regulatory standpoint to say to doctors and hospitals that it's your requirement to, for example, fill out every field. But what you can do over time is set standards for accuracy. And one of the things that we had said in our previous recommendations is that there ought to be some consideration for the Nationwide Health Information Network governance rule of minimum accuracy standards.
... Ultimately it will be hugely problematic if the weakest link in the chain is not matching data appropriately and it's getting exchanged with other participants and it was wrong from the start. So the idea here is to have the technology support good patient matching practices and then maybe promulgate some of those best practices through Nationwide Health Information Network conditions of participation.
Next stepsANDERSON: Finally what are the next subjects that the tiger team likely will address? I understand you're soliciting ideas from the public now through your blog?
MCGRAW: It may have looked like a haphazard process in terms of the topics that we've taken on, but it's always been our goal to take the nationwide electronic data sharing principles that the ONC first put out in December of 2008 ... look at those principles, look at what current law already requires of covered entities and then think about where the gaps are in both policy and best practices and try to flush those out in a series of recommendations. We have done a fair amount of work, but we suspect that there is more to do.
Certainly, most of our work to date has been assuming a world of what we call "push" transactions, where the data holders are the initiators of disclosure and make decisions about with whom to share data from their records. ... It's a different environment when you talk about a query/response type ["pull"] model where you have a patient and you're looking for data about him or her and you need to go out and find it in the health information exchange ecosystem. Even HIPAA doesn't really have that many rules about how you collect data; it has a lot of rules about what you can do with data once you have it. ... We had a lot of discussion on our last call about looking at query/response models. We want to make sure that we've taken care of the policy gaps even with respect to "push" transactions. And then, ultimately, we want to get beyond the sort of primary data uses that are part of meaningful use and think about secondary [research] data uses too. But we want to build the foundation for the primary uses and make sure that's strong and then move on from there.
But we'd love to get input from the public about where the gaps are and where we should go from here.