My last post discussed the trust framework many believe is a necessary prerequisite for protecting private information as health information exchange becomes more wide- spread. This post will take up the subject of trusted identities. Central to this discussion will be an understanding of digital certificates and how they are used. There is an ecosystem built around digital certificates that few clinicians understand. While I am not an expert in the privacy and security field, I have taken an interest in learning more about this topic so I can outline some of the basics. This information could not be timelier. On May 23rd during the meeting of the Privacy and Security Tiger Team of the Health Information Technology Policy Committee (see agenda and slides) a presentation on digital certificates was a major topic on the agenda. Yesterday, May 24th, there was an interesting exchange between two knowledgeable bloggers (Dr. John Halamka and John Moehrke) about certificate management and provider directories. And today the S&I Framework managed by ONC held its first work group meeting on digital certificates and directories. It was evident from the open discussion that there is a wide disparity of opinion about the course ahead.
One of the major prerequisites for electronic health information exchange is that the partners involved in the transfer of private patient information know and trust each other's identity. Most are familiar with the concept of trusted identities because of experience with online banking and e-commerce. There are any number of reasons why this is a challenge when health information exchange is considered. Often, the parties to information exchange do not know each other personally. Also, the most practical techniques utilize the public Internet infrastructure. We know that there are numerous sophisticated malicious and criminal users of the Internet ready to modify or steal information and health care providers have both moral and regulatory obligations to protect personal health information. The federal government has a significant stake in identity management. A very informative draft synopsis, National Strategy for Trusted Identities in Cyberspace was published last year and is a must read for those with interest in this area. If you read this document you will note frequent reference to the concept of a trust framework and ecosystem that was the subject of my last post. Now we will review how identity is currently established in cyberspace.
There are non-cryptogenic and cryptogenic methods to assert an identity. The former take advantage of one or more of the following: something we know, something we have (may use cryptogenic features), or something we are. The most familiar non-cryptogenic method is something we know- usernames, passwords, and answers to secret questions. What we are consist of biometrics- fingerprints, retinal patterns, and facial appearance, for example. Cryptogenic methods often utilize tokens-also known as keys or digital certificates. Digital certificates are associated with a number of electronic privacy and security functions everyone will recognize- they are used for electronic authentication processes, they are a required component of many encryption processes, and they are utilized when creating digital signatures.
A digital certificate is either software or hardware based. A good introduction to digital certificates is found here. The X.509 standard is a well-accepted and widely utilized standard. Digital certificates are issued by a Certificate Authority (CA). The certificate authorities perform identity proofing whereby they verify that their customers are who they say they are. The thoroughness of the identity proofing is determined by the policy and procedures established by each CA. This can range from something as simple as collecting/assigning username and password assertions to requiring in-person verification of identity documentation and additional information. The process for becoming a CA has few requirements. Acquiring the least trustworthy certificates involves creating the certificate code using the X.509 standard and then self-signing. Most CAs employ more robust identity proofing procedures. The important point is that different CAs engender different levels of trust. A good resource for an in-depth introduction to levels of trust is this NIST publication.
Special requirements concerning CAs that issue certificates in the health information exchange realm can be expected soon. The computer systems operated by agencies of the federal government already only accept certificates from officially vetted CAs. In order for EHRs to send information to CMS, ONC, or CDC, they will need to use digital certificates issued by federally approved CAs. This a key concern to implementations of the Direct Project. The federal advisory committees will continue to evaluate the relevant issues this summer so stand-by.
I still need to discuss how certificates are discovered by information exchange partners, exchanged, and used. But those are hot topics for future posts.
Wednesday, May 25, 2011
Sunday, May 8, 2011
The Trust Framework in HIE
One of the major barriers to more rapid expansion of health information exchange has been concern about protection of patient privacy. Therefore it is critical for the health IT community to develop foundational policies and procedures to provide reasonable assurance that private information of patients will be protected. On the one hand, there is no lack of regulatory privacy protections currently. Consider the HIPAA privacy rule and Meaningful Use stage 1 requirements, for example. However, some question whether current policies and technologies are mature enough to adequately protect personal health information. The frequent media coverage of large and small data breaches, including those that are the responsibility of health care entities, does little to engender public confidence. So what efforts are currently underway?
There are numerous governmental, public, and private groups working on this challenge. The Office of the President produced a draft federal plan that addressed cyber security issues in 2006. More recently the Privacy and Security Tiger Team of the Health Information Technology Policy Committee (HITPC) and the Privacy and Security Standards Workgroup of the Health Information Technology Standards Committee (HITSC) have each been tackling various aspects of protecting information privacy. The archives of previous meetings available at the ONC website are a rich source of information concerning their work. A recurrent theme is the need for an underlying trust framework to enable wider adoption of electronic health information exchange, especially if transport will utilize the public Internet infrastructure. Let's learn more about the meaning of a trust framework.
There are numerous components to a trust framework. The purpose of the framework at its most basic level is to ensure that partners involved in health information exchange can trust each other. One of the first steps is developing the policies, governance, procedures, and technology needed to authenticate one party to the other in order to facilitate access control decisions. A good explanation of a trust framework is provided in a course produced last year by the National eHealth Collaborative. NHIN 104 explains how the federal government has chosen to develop a trust framework to support NHIN Exchange. This trust framework concept can be scaled to encompass general health information exchange across the US. The subject for my next post will be Trusted Identity.
There are numerous governmental, public, and private groups working on this challenge. The Office of the President produced a draft federal plan that addressed cyber security issues in 2006. More recently the Privacy and Security Tiger Team of the Health Information Technology Policy Committee (HITPC) and the Privacy and Security Standards Workgroup of the Health Information Technology Standards Committee (HITSC) have each been tackling various aspects of protecting information privacy. The archives of previous meetings available at the ONC website are a rich source of information concerning their work. A recurrent theme is the need for an underlying trust framework to enable wider adoption of electronic health information exchange, especially if transport will utilize the public Internet infrastructure. Let's learn more about the meaning of a trust framework.
There are numerous components to a trust framework. The purpose of the framework at its most basic level is to ensure that partners involved in health information exchange can trust each other. One of the first steps is developing the policies, governance, procedures, and technology needed to authenticate one party to the other in order to facilitate access control decisions. A good explanation of a trust framework is provided in a course produced last year by the National eHealth Collaborative. NHIN 104 explains how the federal government has chosen to develop a trust framework to support NHIN Exchange. This trust framework concept can be scaled to encompass general health information exchange across the US. The subject for my next post will be Trusted Identity.
Labels:
Cyber Security Draft,
HIE,
HITPC,
HITSC,
Trust framework
Subscribe to:
Posts (Atom)