Home >  Events >  SITH > 

Workshop Feedback

As a follow-up to the workshop, all participants were asked to send a brief response to one or more of the following prompts.   We have aggregated the responses here.

Question 1: From your perspective, what is the one "big issue" that must be addressed to ensure security/privacy of HIT (health information technology)?
Responses

• I will confine my response to HIEs (health information exchanges), because all of HIT seems a bit broad to identify one big issue. For HIEs, I believe issues surrounding patient/consumer consent are the major issue. Specifically, can consent mechanisms be developed that will allow the free flow of information for both primary and secondary uses of health information that will still permit patients/consumers to exercise some control over how their information is shared? Key sub-issues are how to structure sharing options and gather patient/consumer preferences in a usable manner, how to translate these preferences into formal policies, and how to resolve conflicts between multiple sharing policies that are present, e.g. those specified by the patient/consumer, different participating organizations, regulating bodies, etc.

• To ensure privacy in HIT, it is important to provide patients (and other subjects of HIT systems) with some usable capability to control the collection, storage, and sharing of health-related information about them. At the workshop, I learned how difficult it may be to accomplish this goal, in a meaningful and yet usable fashion.

• Three part response:

1. HIPAA is an impediment to the useful transfer and maintenance of patient information. It must be amended to reflect reality, patient needs, and research needs.
2. Although it is heretical to say this, I think we need to consider a unique patient ID. The errors generated by the lack of a unique patient ID are horrific.
3. We must convince the populace that insurance companies have greater interest in twisting your data than does the government.

• I'm not sure there is one specific issue to be honest, but here are the two largest ones in my mind: i) securing the patient devices that will be used by non-experts, this ranges from home computers where people will access their data, to securing their cell-phones, which will be used as computational hubs in personal piconets of health sensors (I'm actually wondering is we won't want application specific hardware in these cases, which are not general purpose); and ii) in the absence of a coordinated hierarchy, the composition of a number of different systems from different vendors is sure to have numerous security problems. Therefore, in my opinion, a specific sets of standardized APIs and security protocols need to be defined, and their use mandated in scenarios which meet certain security or privacy requirements. This will permit some form of secure interoperability.

• A clear theme that came out during each of the panel sessions, and that was reinforced during casual discussions between and after the formal workshop sessions was that usability, particularly understanding user perceptions of privacy would be key to the success of HIT.

• Try to get a better handle on what the "requirements" are (for privacy, records management, security in general, etc.) before we spend too much time thinking about solutions - and that means having the policy folks and the engineers discuss what may be practical as the policy elements are defined/refined/specified.  And bear in mind (as I know you well understand) that the more flexibility that is desired in any system, the more complex the design has to be; I generally agree with others who have mentioned that it is better to start with a minimal design and make it work, than to try to cure world hunger out of the box.

• We need to deal with consent propagation. We need to better address the rights and responsibilities of intermediaries.

• How to gauge and implement methods that address trust from users, even more than technical security measures.

• Organizations working to resolve the challenges of HIT need to be prepared to offer clients "reasonable assurance" that their health information will be protected, that they will be notified should a breach occur, and that they will have the opportunity to redress identified losses.

• Two-factor requirements for prescribing controlled substances.

• Framework and platform are required to serve as a middle ground between policy makers and engineers, so that the complex policies can be expressed by the policy maker and simplified into specifications that engineers can work on under different contexts.

Question 2: For you, what was the most important "lesson learned" from the workshop?
Responses

• Privacy is an ill-defined concept, and further we should not try to define it generally in order to make specific headway on current technologies. This is not an optimal strategy, but one that recognizes new systems will be deployed and built in the very near term due to political and business reasons. We need some reasonable, robust definition that is far from perfect, but whose implementation would guarantee some minimal privacy rights. My view is we will have to legislate against either the mining or use of this private information. I don't see a technical solution in the timeline necessary.

• I learned that many HIT projects are already built, and in use. This means that we need to not only work to understand what we can do to build ideal HIT in the future, but we also need to collaborate immediately to ensure the privacy of those whose health information is already in a health information system.

• Since HIT is not yet at the point where security/privacy can be "ensured", trustworthiness and accountability of involved individuals and organizations is essential for their creditability and viability.

• There is no perfect way to secure data, and all require some leap of faith for the user.

• Three part response:

1. How hard it is to ensure protection of privacy.
2. Once again, how privacy and utility of data are so often in conflict.
3. How important it is to make people understand the difference between de-identified data and fully PHI-linked data.

• For me, the biggest surprise was learning that, from the clinical perspective, the focus was much more on using the results of data analysis to try to improve the health care system (indirect benefits of the use of health IT), rather than direct benefits such as eliminating the need to fax and/or copy information, reduce human errors, eliminate redundant tests, etc.

• Lessons from Helen Nissenbaum's book, "Privacy in Context".

• It is important for us to keep a positive attitude and focus on problems that have accessible technical solutions. There is a threat that researchers will not make progress in the area because they are discouraged by the size and complexity of the task. We must believe there are things we can do that will help in a meaningful way even in the short term.

• While I knew that the standards/requirements space was in a state of early evolution, I was modestly surprised to find that some others who are eager to discuss "solutions" were not as aware of the immature nature of that space.

• Policy makers and engineers need to work closely together to understand and ensure security/privacy of HIT.

Question 3: If you could decide how the HITECH budget was to be spent, what would you target first?
Responses

• In defining, and giving base implementations to security protocols that will permit secure and relatively private interoperability between a number of HIT systems, be they EHRs or Health Sensors.

• It seems like open source systems are more secure than closed (though I am no expert on this) - should the architecture behind HIT/PHR/EHR be open source?

• This is a tough one. Perhaps the choice is between getting EHR systems to the many small doctors' offices that are still not electronic, or connecting the large providers together so they can share information seamlessly. Both goals are worthwhile and I would hope that they could both be advanced by HITECH, so I guess I will have to choose not to choose between them.

• I certainly would emphasize the importance of advances in privacy and security. In this space privacy is probably the tougher challenge.

• Before we decided to subsidize vendors to the tune of $67 billion, we should have first ensured we have usable systems. The money therefore should have first gone into developing usable systems, human factors analysis, efficiency improvement, true interoperability, and better implementation skills. Currently, we are investing billions in the qwerty keyboards of HIT. They reflect the detritus of earlier efforts, and require massive work to reach almost acceptable levels of use. They are primitive, non-responsive, too often dangerous, and too clunky to improve in the near future. That said, I emphasize that I so very much want acceptable HIT and that I am totally committed to the future of HIT as a major benefit to patients, to greater efficiency, and to medical research. We must all work hard to create better HIT. At the moment, alas, it's the triumph of marketing over reality, and of regulatory capture over rationality. We very much need HIT, but not as a vendor full employment program. As a nation, we need HIT as the key element of a national health research effort, as a tool for greater efficiency and cost reduction, as a patient safety improvement effort, and as the foundation of evidenced-based research.

• As is repeated so often in security work, the time to understand the risks is pre-implementation. This means that before we invest more in building systems, we need to understand what users' true privacy concerns are, and build systems that conform to users' expectations. Thus, the place to target the HITECH budget, at least in the immediate future is in understanding what users (both patients and health care providers) want and will accept with respect to HIT.

• Build a benchmark system of HIT.

• Medication management and e-prescribing.

• Getting the standard settled - and again, not just for security/privacy but also for taxonomies, records formats, data definitions/standards, etc. Right now there are multiple vendors promoting multiple solutions in the hopes that each will become the "Microsoft" of health IT. That has led and will continue to lead to chaos and lack of interoperability as each jockey for position.

 

Photo by Joseph Mehling '69