This appeared a week or so ago.
By Mary Mosquera
Friday, March 04, 2011
The Health IT Policy Committee has expressed its support for two-factor authentication for users who remotely access electronic health information through virtual private networks or online applications.
A committee panel, the privacy and security tiger team, sought the experience of committee members, many of whom are physicians, to help them understand the practicality of requiring two factors before they finalized their recommendations.
The tiger team is weighing user authentication among its recommendations to support privacy and security in health information exchange. They believe that more than just a password should be required for to assure that a person is who they claim to be.
Remote access is generally considered a greater security risk than on-campus and local access.
However, the panel members could not agree on whether to require two factors and, if they did, whether to specify the types of factors to be considered, said Deven McGraw, chair of the privacy and security tiger team.
She is also director of the health privacy project at the Center for Democracy and Technology.
Among the physicians offering their experience, Dr. David Blumenthal, national coordinator for health IT, said that for years he used two-factor authentication in the form of a password and randomly generated number. It took a while to get used to the process.
“I stopped noticing it after a few months,” he said. “It’s a behavioral issue. But it’s a real issue, and one that requires persuasion and management to overcome.”
Providers must establish policies to prove identity and to authenticate users who access electronic health records, consistent with the Health Insurance Portability and Accountability Act (HIPAA).
The tiger team has cited as a model the assurance levels described by the National Institute for Standards and Technology (NIST) in its number 800-63 privacy and security document, including using a knowledge token, such as a password, and a hard token, such as a one-time assigned password.
The issue this raises for all of us is, assuming at some point there is some patient information available within the PCEHR system - just how will access to that information be managed?
On the basis that, as far as an individual is concerned, access will be via a PCEHR system portal, what level of identity verification would be provided.
The options would appear to be basic and a variety of two factor approaches. For health information it would seem unlikely that simply issuing a password would be good enough.
As soon as you move beyond this you are looking at a range of options, all of which (smartcard, Medicare card stripe, USB key or other one time use token such as the banks provide) will come at a considerable cost and will need a whole infrastructure to manage and maintain them.
It would be interesting to know just how much is in the budget for this - recognising that it seems likely that NASH or some equivalent will be used for provider verification.
Of course the issues of all the varieties of access sharing one might envisage just makes the sense that it will be possible to provide reasonable confidence as to the protection of private information without considerable complexity and cost seem unlikely.
Again I guess we will have to just wait and see!
To put all this in context the following is useful - being from the most advanced Healthcare Portal that is publicly available I am aware of - excluding that from Kaiser and similar organisations which have a clear membership focus.
About Sundhed.dk - patient portal
Prior to Sundhed.dk the Danish health service consisted of silos of information which comprised of individual solutions and databases with no means of integrating it together. Sundhed.dk helped share the information contained in these individual databases making the information available to the users 24/7.
Sundhed.dk was broken down and implemented in three main phases. The first phase which was launched in December 10th, 2003 was an informational portal. The next phase aimed at decreasing the number of duplicate lab orders by consolidating information from various sources into one central source. In 2004, the final phase of the portal was implemented, the portal now uses a patient record for each patient that has all the information necessary to identify a patient and his/her medical condition at the point of care.
Sundhed.dk is a consent based model where patients give permission either online or during the treatment. During treatment the patient's health care professional can receive verbal consent and then fill a form online on behalf of the patient. The consent information is available on Sundhed.dk and the patient has the ability to verify who accessed his/her information.
In January 2009, the site registered 304,000 unique visitors, 448,000 total visits and 2,800,000 page impressions. These numbers correspond to a total Danish population of 5.4 million.
Sundhed.dk is a complex platform and has high maintenance costs. The reasons for such high maintenance costs are the implementation approach which is very fragmented, law of privacy which limits the sites functionalities, and lack of a common data model.
In spite of this limitation Sundhed.dk provides every citizen and every health professional with access to personal health information and online services, provided that the have a digital signature. A digital signature is free and available to every person in Denmark above 15 years of age. Sundhed.dk then personalizes its pages based on the logged users attributes and shows relevant information especially around online lookups which are customized to the logged user's treatment needs.
The health professionals are including Sundhed.dk in their own channel strategy using all or a selected range of services.
So, in Denmark it is digital certificates for all.
For those who want a bit more on what is done and might be required elsewhere the following links may be useful:
and on a proposed approach:
The bottom line is that if you plan put healthcare records on the web you will need to design in and least bank level security and access control and this will not be cheap to operate and maintain!