Effective (Cybersecurity) Regulations - focus on What, not How.

There is many indications that in the USA, President Obama, may promulgate an Executive Order on CyberSecurity. This executive order due to the lack of law maker movement on the same topic. There is a strong feeling that there is a needed to keep digital information and systems 'safe'.

White House moves on cybersecurity

I hope they learn from Healthcare. The focus on Privacy and the use of the Breach Notification system has had measurable effect. Clear requirements of ‘what’ to do, not ‘how’ to do it; with clear and executed ramifications for failure. It is amazing what a little ‘sunlight’ will do.

Largescale Health Data Breaches Declined in 2012 OCR Data Show

Healthcare used HIPAA and HITECH, two regulations that defined the outcome expected. As well as the OCR 'wall of shame' for breach notifications. These are good examples of regulating to the outcome, not the means. This is a general pattern not specific to healthcare or to security. But applicable to all things that can be regulated.

To be effective and to be long standing a law needs to be independent of technology. This is why I point out that the regulation should be about 'what' needs to be done, or what the good outcome should look like. When it is goal oriented a law/regulation can be met by an ever evolving set of technology and policy. Technology that can adjust with time to incorporate new technology and new policy as needed. 

When regulation over-extends and explains 'how' to achieve the solution, we end up with a law that will not be as effective and will not age well. It will not be as effective, as many will try to figure out how to get around the specifics. They have some reason to not agree with the 'how' indicated. This is often simply, Not-Invented-Here. A prescriptive regulation or law will also not be as effective as soon as the landscape changes. As the attackers learn new vulnerabilities  As technology changes. As new use-cases come about, such as mobile applications.

Regulate the 'what to do' or 'what is the result desired'. Don't regulate 'how to do it'.

Guidance Regarding Methods for De-identification of Health Information

I have been working on De-Identification for many years, including being one of the major contributors to ISO 25237 on the subject, and DICOM Supplement 55 and 142. I think that the algorithm for De-Identification is rather simple, but it is contextual. Start with the presumption that you can't have ANY data, and provide your arguments for each and every attribute. Start with the most important attributes to your use-case, the context of the de-identification. If you want something that falls into the identity or close to identity space; then how badly can I mangle (actually well understood algorithms) the values before they become useless to you. When you take the attitude that you don't deserve any of the information you tend to end up with the minimal information that you need to fulfill your use-case.

I have placed these concepts into ISO and DICOM standards, IHE Handbooks, and my blog... But it is so much more powerful when a government says the same thing. It is not more powerful because they are so much smarter, but because by following their advice, even if it is the same advice, you get a 'pass'. One might say a 'get out of jail free' card. Which is a fallacy, but perception is as important as reality sometimes. This month both the USA and UK have released their advice on De-Identification. I haven't compared them, but will be doing that while harmonizing them into the IHE Handbook. I suspect that there is nothing truly new. I can say that my quick look indicates that they are truly useful. So although I might see these as purely politics, I do see that they have put very useful thought into their guidance.

The USA has provided us:

From: OCR HIPAA Privacy Rule information distribution [...] On Behalf Of OS OCR PrivacyList, OCR (HHS/OS)
Subject: Guidance Regarding Methods for De-identification of PHI in Accordance with HIPAA 

November 26, 2012
Today, OCR released guidance regarding methods for de-identification of protected health information in accordance with the HIPAA Privacy Rule. This guidance fulfills the American Recovery and Reinvestment Act of 2009 (ARRA) mandate that HHS issue such guidance. In response to this mandate, OCR collected research and views regarding de-identification approaches, best practices for implementation and management of the current de-identification standard and potential changes to address policy concerns. OCR solicited stakeholder input from experts with practical technical and policy experience to inform the creation of guidance materials by organizing an in-person workshop consisting of multiple panel sessions, each addressing a specific topic related to de-identification methodologies and policies. The workshop was open to the public and was held March 8-9, 2010 in Washington, DC. The guidance synthesizes these diverse perspectives. It can be found at http://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/De-identification/guidance.html.

The UK last week provided

News release: 20 November 2012
The Information Commissioner’s Office (ICO) has today published its data protection code of practice on managing the risks related to anonymisation. The code explains how to protect the privacy rights of individuals while providing rich sources of data. 

The code comes at a time when the UK is putting more and more anonymised data into the public domain, with the government’s open data agenda allowing us to find out more than ever about the performance of public services and holding public bodies to account.
Announcing the publication of today’s code of practice Christopher Graham, UK Information Commissioner, said:

• “We have published our code of practice on managing the data protection risks related to anonymisation to provide a framework for practitioners to use when considering whether to produce anonymised information. The code also aims to bring a greater consistency of approach and to show what we expect of organisations using this data.
• “Failure to anonymise personal data correctly can result in enforcement action from the ICO. However we recognise that anonymised data can have important benefits, increasing the transparency of government and aiding the UK’s widely regarded research community.
• “We hope today’s guidance helps practitioners to protect privacy and enable the use of data in exciting and innovative ways. We would also like to thank those people who took part in our recent consultation and helped today’s code of practice become a reality.”

The ICO has also announced that a consortium led by the University of Manchester, with the University of Southampton, Office for National Statistics and the government’s new Open Data Institute (ODI), will run a new UK Anonymisation Network (UKAN). The Network will receive £15,000 worth of funding from the ICO over the next two years to enable sharing of good practice related to anonymisation, across the public and private sector. The network will include a website, case studies, clinics and seminars. 

Today’s code contains a framework to enable practitioners to assess the risks of anonymisation related to data protection and identification of individuals. It also includes examples of how successful anonymisation can be achieved. This includes an explanation of how personal data can be anonymised for medical research purposes, how individuals’ information can be anonymised when responding to Freedom of Information requests, and how customers’ data can be anonymised to help market researchers analyse people’s purchasing habits.
Download the new data protection code of practice Read our anonymisation topic guide

See also:

• The Emperor has no clothes - De-Identification and User Provisioning
• De-Identification is highly contextual 
• Redaction and Clinical Documentation

Thankful and Hopeful for Healthcare progress

There is so many good things that happen when data is allowed to move. I have dedicated my career to enabling healthcare data to move when appropriate. I follow the guiding principles of Privacy (OECD, USA, EU, Safe Harbor, Privacy by Design) . These are expressed in multiple forms but generally all well align. The appropriate movement of healthcare data can enable so many wonderful things to happen, things well beyond our wildest dreams today. This is what drives me, this is my mission.

I am Thankful for some efforts that I was a part of this year. I can’t say that they all turned out exactly as I wished, but they did meet my overall mission, to get data moving when authorized.

• Healthcare around the globe is aligning on standards based Document centric Transports with reasonable security models. In the USA this is being pushed by Meaningful Use. Document centric transport is not the ultimate goal, but it is an example of ‘good enough’. I think it is very much the sweet spot between many forces: Privacy, Clinical Accuracy, Provenance, and Medical Records. Advanced security and privacy are being worked on using realistic use-cases and mostly a realistic viewpoint on timeline. In the USA this is being pushed by the Data Segmentation for Privacy. It is unfortunate that much re-invention is happening, but sometimes one must allow others to do this.
• Security/Privacy Audit logging is making progress and visibility but still not a forefront item, it likely never will as it isn’t sexy and can only show bad things have happened. But this year we saw enhancements in this space. We are nowhere near good-enough. A privacy office still must do so much work to pull together a simple accounting of disclosures. If it is hard to do this on-demand, I am sure there is not daily reviews of the audit logs.
• Patient access and correction are starting to make progress. I am not one that says that there should be some patient centric database in the cloud. I am however one that indicates that we must enable patients to have access to their data. Access and manipulation of data, my mission, is not going to be the dominated by professionals as it has in the past. Once the patient gains access to their data they can do wonderful things with it as well. Along these lines I am excited about RESTful interfaces for healthcare. Not just willy-nilly RESTful interfaces, but reasoned interfaces that are purpose driven and harmonized with backend and more mature infrastructures. REST is not a magic thing, it is one of the appropriate tools to use. Fitting that tool in with the others is just as important as using it.

The Patient is being recognized as having Privacy rights. Privacy rights not only allow a patient to control their data, and to understand how their data is used; but it also enables them to access their data and get it corrected when it is wrong. These are fundamental Privacy Principles; it is quite exciting to see them all progressing. Getting the data to move is what is important, the creative ways to add value through access to the data is what will revolutionize healthcare.

I will continue to work on my mission. There is still technology that is needed, I just think that we have good technology today. What we don’t have is the political and organizational will to leverage it.

With the continued Obama Administration I am Hopeful for some key Political movements in Healthcare

• User Identity needs to be fixed. This is not a technical problem, we have the technical standards. This is a political problem. We have hundreds of individual user accounts because all services historically had to do this, and none of them would trust anyone else. We need a system where by the user chooses when to have a different account, and when to leverage one they already have. In the USA NSTIC is working on user identity in the internet space. This will not address organizational users, specifically how one organization needs/should trust the users in another organization. Federation technology is clear and easy. We need movement, it is great to see Google, Facebook, Twitter, and others leveraging these technologies and making them available. The business of identity-providers will be a tough business to be in over the next 5 years. But we will all be better off.
• Patients need an identity, not this mess which is cross referencing. Cross-referencing will work, but is the worst of all possibilities. Cross-Referencing will make mistakes, a mistake in healthcare at best is a privacy violation at worse a leads to a treatment error. Cross-Referencing exposes MORE of the patient identity to more organizations and thus more potential misuse. This problem is being addressed more outside the USA. I am excited at what is going on in Europe and beyond. The USA must reexamine the historic attitude on a patient identity, and examine the problem in context of today and the future.
• Privacy enhancement through simplification and unification. This too is not a technical problem. We need in the USA to focus on having a unified privacy policy that is good-enough. The technology will continue to change, but it is very difficult to work on advances when the sands shift underfoot. We need simple patient choice to be put forward as good-enough. It is true that simple opt-in will not work for some, but they will work for most. Let’s get this system in place so that we can then focus attention on how to advance it. We don’t have a simple opt-in because we have multiple layers of conflicting privacy regulations. Privacy Principles give the patient choice, simple as that. I know some states want to use implicit consent, but it is time to reexamine this. There is plenty of proof that when patients are given choice, informed choice, that they choose to share.
• Roll out of Exchange, and put to bed Direct. We need to get data available, not continue to do one-by-one interactions that somehow need to predict where the data needs to go. Direct is a great replacement of the FAX, it is not a good solution for anything else. I am glad that we have aligned on Documents, this was my goal when I conceded and helped create Direct. Document is the most important advancement. But we must encourage eHealth Exchange to make data universally available. This is far more important that being able to universally discover doctors. Movement of data is the key.
• Please fix the Patent system. Patents are essential, but the use by trolls is clearly not what the Patent system was intended to enable. Our courts are spending far too much time determining if patents are valid or not. This is the job of the Patent Office, prior to issuing a stupid patent. The court system is a hugely expensive way to deal with this problem. Our courts should be doing what the courts were designed to do, things like prosecuting inappropriate violations and invasions of Privacy. 

Privacy does not get in the way of progress. When you ignore privacy, it will come back to hurt when consumers find out about the violation and invasion of their privacy. Design Privacy into your system from the start, and be transparent with consumers. Consumers will reward openness and transparency.

I have many articles on these topics

IHE-IUA - Internet User Authentication for HTTP profiles

Profile Proposal for 2013 development in IHE ITI
This is a profile proposal that the IHE ITI committee will most likely take up in the 2013 timeframe. This is just a proposal so input is important as well as support from those interested and those with experience. Note I took liberties with the name, the author has called this "OAuth for HTTPS access". I simply think that this new title puts this new profile in the family of Enterprise User Authentication, and Cross-Enterprise User Assertion. Plus I don't like putting technologies into the title of a profile, actually don't like the solution to lead as the problem should be the point of the profile. This will next be discussed at the IHE ITI Technical Committee meeting in December at the Mitre offices in DC. The rest of this blog post is the  Detailed Profile Proposal unedited (note, I think OAuth 2.0 [RFC 6749]) is now released, See the IETF OAuth status page

Summary
The HTTP based transactions, like those in MHD, need authorization services as part of their security environment. OAuth and Kerberos are examples of such services. Kerberos is used within enterprise, but is not accepted for cross enterprise use. OAuth is being used and extended for such use.

The authorization process must allow a healthcare service provider to support multiple authorization services.

The customer/client/patient must be able to select a preferred authorization provider independently of their selection of a healthcare service provider. The authorization provider assures the healthcare service provider that the client software application is authorized to request and use the services of the healthcare service provider.

There is already a market for authorization services in the commercial environments on the Internet. Early versions of OAuth 1.x are in use by Google, LinkedIn, Facebook, and other well known providers. Experience with this has driven creation of a new version of the OAuth standard that can be profiled for different use environments. OAuth 2.0 is not complete in itself; it must be profiled to meet the needs of specific market segments.

IHE has the expertise in the needs of the healthcare market, and is structured to create profiles of existing standards. This should mesh well with the structure and methodology of the OAuth 2.0 standard. By using the same standards as the commercial sector, we increase the acceptance of the healthcare profiling by commercial authorization providers.

There are already prototyping efforts by ONC and others to develop implementations and confirm usability of OAuth in a healthcare setting. The regulatory and legal requirement for authorization services is clear. The market demand that authorization services be independent of healthcare provider services is also clear.

The Problem
HTTP-based transactions, like the RESTful transactions in the MHD Profile, lack a standard authentication and authorization mechanism. Many RESTful activities have no need for such mechanisms. The RESTful activities used in MHD and other profiles take place in a healthcare environments, and an authorization mechanism is needed for some kinds of healthcare access.

An authorization mechanism is needed for MHD for patient access by tablets and smartphones, and in expected uses for provider access by tablets and smartphones. Smart devices, such as blood pressure monitors, delivering their results to providers need authorization mechanisms.

Providing an authorization mechanism as a profile that can be grouped with MHD and other RESTful profiles will enable their use in the anticipated deployment environments.

Target EnvironmentThe devices are restricted in function and capability, typically tablet and smartphone devices. Their network and storage capabilities are constrained to those provided as part of the device environment.

• Ownership and control varies, the device may be
• Patient owned and controlled.
• Provider owned and controlled.
• Third party owned and controlled.
• Combinations of ownership and control.
• The authorization service must be usable over HTTPS. It is assumed that TLS will be available and used to protect and authenticate the communications. (Bi-directional authentication may be an issue. This needs to be resolved.)
• Use over HTTP is desirable, but the lack of protection within HTTP means that it would only be acceptable in controlled environments. Use within a single facility over protected networks like VLANs is an example of appropriate use.
• Only HTTP headers can be extended and used. It is too difficult to modify some of these devices to use completely new protocol stacks.

There will be multiple authentication and authorization servers in the environment. It is expected that a provider will negotiate with and accept at least several different authentication servers for use with that provider. It is expected that the person or organization controlling a device will select one of those authentication servers.
The authentication server and authorization servers may be provided by the healthcare provider or may be an independent third party. The system chosen must accommodate reasonable combinations of these.
The devices may have multiple applications and may chose to use different authorization servers for different purposes.

Use Cases
The following five use cases will be considered initially for profile purposes. This is not an exhaustive list and one of the early tasks of this project will be re-examination of the use cases to combine those that are duplicative and add those that are considered appropriate. (Appropriate additions will motivate and explain additional requirements on the protocol beyond those already driven by these use cases. There are far too many different potential use cases to accept any further use cases unless they reveal new requirements for authorization services.)

• A patient with a mobile device wishes to retrieve a medical document to which they have authorized access. 
• A provider with a mobile device wishes to retrieve a medical document to which they have authorized access.
• A patient with a mobile device wishes to provide a new medical document to their provider.
• A provider with a mobile device wishes to add a new medical document to a patient record.
• A smart device wishes to add a new medical document (containing a device report) to a patient record.

All of these need authorization steps, and the authorization transactions follow the same pattern. The use cases may differ in terms of details about the individual transactions, etc. The use cases also are likely to have different threat environments that need to be analyzed.

All of the existing standards follow a very similar transaction pattern. The diagram below uses the terms from the OAuth standard, but the other standards fit this diagram with only the names of the transactions and actors changed.



The Client will make a request of the Authorization Server. There is may be other HTTP traffic involved as part of the authorization process. This traffic might not be specified in detail by the authorization profile because they are provider specific. The result is an authorization response providing a ticket of some sort that can then be used in communications with the Service Provider.

The client will use that ticket, and perhaps other related information, in the HTTP request headers to inform the Service Provider that it is authorized to make this transaction.

Standards & Systems
The most likely candidate standard is OAuth 2.0 http://datatracker.ietf.org/wg/oauth.

Other standards candidates exist, but none of these has gathered significant acceptance in the cross enterprise environment:

• HTTP Kerberos, which has moderate acceptance within enterprise but none across enterprises http://datatracker.ietf.org/wg/krb-wg.
• HTTP LDAP authentication
• HTTP Password
• HTTP SAML
• Other developing standards (To be explored)
• Proprietary systems

The OAuth 2.0 standard is a framework that is not in itself complete. It is expected to be profiled to meet particular use case needs.

Technical Approach
All of the candidate standards take a similar approach. They match the transaction flow shown above. The ITI effort will not invent new methods. It will profile an existing standard for authorization. We do not expect widespread acceptance if we invent a new method.

New actors

• HTTP Authorization Client – the client device
• HTTP Authorization Server – the system providing authorization services
• HTTP Server – the system providing the HTTP service.

Existing actors
These new clients will group with existing and other new actors. For MHD, it is expect that the HTTP Authorization Client would be grouped with Document Source and Document Consumer. The HTTP Server would be grouped with the Document Recipient and Document Responder.

(It may be that after review we will decide to use options rather than grouping to accomplish this function. For now, we will proceed assuming that the grouping function will be used to document the behavior.)

New transactions (standards used)
The two new transaction will be:

• Authorization Request. This is likely to be an OAuth authorization request. It is between the client and the authorization server.
• Authorization Service Ticket: This is likely to be modifications to the HTTP headers in a RESTful transaction. 

In the case of MHD, it would be modifications to the HTTP headers in the Put Document Dossier [ITI-65], Get Document Dossier [ITI-66], Find Document Dossiers [ITI-67] and Get Document [ITI-68] transactions.

Impact on existing integration profiles
HTTP based transactions like MHD may need to have options added so that implementations can indicate the ability to perform and use authorizations.

New integration profiles needed
A new profile will be created to describe the new actors that request, provide, and use authorization services, to describe the new authorization transaction, and to describe the HTTP header modifications needed to use the authorization results.

Breakdown of tasks that need to be accomplished
The major work items to be performed are:

• Identify the threat environment models for the use cases. One important issue will be the extent to which we attempt to deal with the problem of hostile platforms. The likelihood that patient owned and controlled devices are penetrated by malware is high. There is a near certainty that at least some of the devices involved should be considered hostile platforms. OAuth 2.0 has a threat document that may contribute to this effort. http://datatracker.ietf.org/doc/draft-ietf-oauth-v2-threatmodel
• Evaluate the available standards in terms of how well they protect against the expected threats.
• Select a standard
• Profile the standard for the expected threat environment and use cases
• Clearly identify the limits of applicability for this profile. One of the greatest risks for security profiles is their use in environments where they do not provide adequate protection.

Risks
None of the long existing standards has reached widespread acceptance in the cross enterprise environment.

The OAuth standard is still in draft form. Publication as a draft standard is expected in mid 2013. The previous version of OAuth had a number of different problems, although these did not prevent adoption. They did result in different vendors making choices that substantially reduced interoperability between different authorization servers. This made it difficult to support multiple authorization servers for a single service provider.

Working with a draft standard poses risks, but in this case also provides advantages. Since the intention is that the OAuth 2.0 be profiled, feedback from our profiling effort can be used to improve the OAuth 2.0 finished result.

We do not know whether the OAuth 2.0 approach will work and meet with widespread acceptance. The proposal is already the subject of considerable controversy.

There are other less mature standards development activities that claim to be addressing this same problem. They are all significantly behind the OAuth effort in terms of readiness.

IHE mHealth Hackathon

Updated: Official IHE announcement of the mHealth Hackathon

The Mobile access to Health Documents (MHD) profile offers access to the Document Sharing environment from platforms that prefer to use more simple interface technologies. The MHD profile takes the approach of REpresentational State Transfer (REST), a resource centric view; and leverages the technologies readily found on Mobile Devices (HTTP, Atom, JSON). This new interface to the Document Sharing environments is expected to extend the reach to devices and workflows. This new interface is not a replacement for XDS, XDR, or XCA; but rather provides a new programming interface to these Document Sharing infrastructures.

Mobile access to Health Documents (MHD) profile defines a simple HTTP interface to an XDS like environment. It defines transactions to a) submit a new document and metadata from the mobile device to a document receiver, b) get the metadata for an identified document, c) find document entries containing metadata based on query parameters, and d) retrieve a copy of a specific document. These transactions leverage the document content and format agnostic metadata concepts from XDS, but simplify them for access by constrained environments such as mobile devices. The MHD profile does not replace XDS. It can be used to allow mobile devices constrained access to an XDS health information exchange.

The Hackathon to be held at the IHE Connectathon on Wednesday afternoon and evening will provide the attendees insight into this profile and provide an opportunity to play around with it. The Hackathon will bring together implementers of the profile and those that might be interested in using it. The goal is twofold: First to provide a social environment to share experiences with implementations of the profile, and Second to help improve the profile. The profile use of languages that are implemented broadly in many devices and toolkits should offer a chance to develop rapid prototypes of applications. The goal of the rapid prototyping is to play around with the MHD profile interface. The environment will be an extension of the normal IHE Connectathon atmosphere to encourage creativity and problem solving.

Agenda:

• Presentation of MHD profile goal and content.
• Presentation of mobile authentication profile development in 2013 IHE ITI Planning for 2013
• Presentation of a few implementations of the server side of this profile
• Presentation of a few implementations of mobile applications?
• Examination of HL7 FHIR advancement of the concept of MHD. 
• Hacking: given the programming tools of today we expect to see some quick prototyping of applications that could go onto mobile devices and leverage the MHD profile.
• Discussion and Summary

An Implementation Guide is being maintained at mHealth Dossier Guide. We expect to continue to share practices using this wiki, and will publish the results of the hackathon as appropriate.


Updated: Official IHE announcement of the mHealth Hackathon

IHE ITI Planning for 2013

The IHE ITI Planning Committee met last week and prioritized all received proposals. Given the number of proposals we recommend that all proposals be reviewed by the Technical Committee and, after assessment of work load and technical feasibility, our priority be considered when making your recommendation.

The following is the output of the ITI Planning committee. The right side shows the Ballot-based Ranking. This is the priority that the ITI Planning committee is asking the ITI Technical committee to view these work items as. The first three rows are already accepted work items, because these are work items from this year that simply need to be finished off.



The profile proposals and final spreadsheet from the meeting can be found on the Planning Committee folder for next year: ftp://ftp.ihe.net/IT_Infrastructure/iheitiyr11-2013-2014/Planning_Cmte/

Findings Notification – this is a white paper that explores the use-cases of clinical findings notification. This paper is close to being made public.

Document Sharing Re-documentation – this is an effort to fix the Technical Framework Volume 3 where it describes the Document Sharing metadata (XDS, XCA, XDR, and XDM). IHE is trying to present the metadata model in a more comprehensive way that also sets up the various transport types, including MHD in the future.

De-Identification – this is a handbook that will assist IHE domain committees and others to assess any De-Identification needs and help build the appropriate algorithms for an analyzed use-case. This handbook will leverage pseudonym and anonymization mechanisms.

OAuth option for mHealth – this profile proposal looks to fill the authentication gap that exists with the MHD profile. It likely will leverage OAuth, but the actual choice is a technical committee decision. This effort will look at existing efforts such as the USA RHEx effort.

Extend XDW to XCA – The XDW (Cross-Enterprise Document centric Workflow) profile was originally scoped to use with XDS. This profile proposal extends that to XCA environments. This recognizes that many cross-enterprise workflows will take place across the boundaries of XDS.

eReferral Search Services – This profile brings forward some use-cases around the problem of discovering an appropriate place to send a patient for specific referral types. This is likely to be an augmentation of HPD to support discoverability of clinical-services and possibly network-services to support those clinical services.

Full metadata subscription – This profile recognizes that the current Document Subscription (DSUB) profile is too constrained. This profile will bring in additional use-cases and thus subscription types.

Pull-style Notification – this profile brings the use-case where a subscriber to a Document Subscription (DSUB) can’t support the current call-back pattern. This profile suggests that there be a way to queue up the notifications and have the subscriber poll for any outstanding notifications.

What is Next?

Note that the Technical Committee will now assess the technical feasibility of these proposals. Ultimately they will only accept 2 maybe 3 of the non-grey items. The committee really needs participation by those that will benefit from this profiling effort as well as those that have experience in these areas. IHE is a very open group.

Kudos

Kudos to Karen, who even though her house was hit by hurricane Sandy and without power or network and having her flight to Chicago canceled .. continued to chair the meeting from her car sitting outside a public Wi-Fi access point in her neighborhood.