IHE broadens IT Infrastructure Support with extensions and new profiles for 2010

The IT Infrastructure Domain of IHE (Integrating the Healthcare Enterprise) has finalized its scope for its 2010 activities.  It includes three new Profiles focused on back-office support and three extensions to existing interoperability Profiles:

• New Profile: System Directory for Document Sharing (SDDS): This Profile is intended to support the participating systems (EHRs, Clinical IT systems, PHRs, etc.) in the Health Information Exchange (HIE) to discover the web services end point metadata of the infrastructural services. The Profile will target the Cross-Enterprise Document Sharing (XDS) family of Profiles, but will likely be extensible to other network service endpoints.
• New Profile: Healthcare Provider Directory (HPD): This Profile develops a unified approach for authorized users discover healthcare provider organizations/individuals. This Profile will define network transactions to Directories/Registries and the attributes and vocabularies available. 
• New Profile: Enhanced Sharing of Value-Sets (ESVS): Healthcare interoperability is enabled by the combination of syntactic and semantic consistency. This Profile builds upon the IHE Shared Value Set supplement profile to add Value-Set Registry Actors dedicated to vocabulary distribution. This will enable consuming systems to discover and access the most current and relevant set of terminology codes.
• Update to Cross-Enterprise Document Sharing (XDS) to allow updating of document entry metadata held by the XDS Document Registry. This new transaction will allow privileged entities to modify the metadata about a document without replacing the document. This also will include a way to mark a document entry as removed without deprecation. 
• Update to Cross-Enterprise Document Sharing (XDS) and Cross-Community Access (XCA) to support the sharing of document content that will be created at the time of retrieval. This will allow a publishing endpoint to indicate that it is willing to provide an instantiated document upon demand that will include the most current information.
• Update to Cross-Enterprise User Assertion (XUA) to define specific authorization attributes based on the experience of existing regional and national project experience. This extension is looking to enable Role-Based Access Control, Level-of-Assurance, Legitimate-Relationship, and others.

Overall this year the IHE IT Infrastructure committee will be focused on making small adjustments to the overall Healthcare IT infrastructure. This is recognizing the maturity of the Cross-Enterprise Document Sharing (XDS) family of profiles as an infrastructure to build a Health Information Exchange (HIE).

HHS Posts Data Breach Notifications

HHS now has a Web site where they have posted all of the breaches they know about. This will cause some new pressures to secure large databases. I think the more convincing information is that Data Breach Costs Top $200 Per Customer Record. This new web site will also cause some over-reactions and reopen a past discussion that Encryption is mandatory.

The Office for Civil Rights in the Department of Health and Human Services has launched a Web page listing covered entities that have reported breaches of unsecured protected health information affecting more than 500 individuals. More

Related Post on ONC investigation into de-identification

Healthcare use of iPhone presents hidden risks

It should not be any surprise that any platform that is used to deliver sensitive information, such as healthcare information, must be holistically considered within a Risk Assessment framework. There are two REALLY good blog articles on some not-so-obvious risks that occure when the iPhone platform is choosen. The original blog post by MedPage Today blog  is “iPhone Security Risks and How to Protect Your Data — A Must-Read for Medical Professionals.”   This was further elaborated on by IdentityBlogger in the post SpyPhone for iPhone. 

The basic message is that one can't simply worry about their own application, they must look at how the device might be used by the end-user. In the case of the iPhone it is simply too enticing to pull apps down from the AppStore. Apple does a good job of reviewing these applications, sometimes too good, but all it takes is for one malicious application or poorly-written application to get through to cause data leakage.

For any mitigation of this risk, new risks or costs must be considered. If one tries to lockdown the medical iPhone so that it can't use the AppStore would very much inconvenience the user. Try to isolate the application, and the user might not be able to use legitimate cross-over applications. 

HHS appoints Joy Pritts chief privacy officer

I know of Joy Pritts due to her work in Healthcare Privacy. It seems she has the background to do this job. The big question is if this job will be anything other than a figure-head.

The Health and Human Services Department named Joy Pritts, an assistant research professor at Georgetown University's Health Policy Institute, as chief privacy officer in the Office of the National Coordinator for Health IT. More

Georgetown Health Policy Institute bio

How to Write Secure Interoperability Standards

I am an active member of "Interoperability Standards" organizations: HL7, ASTM, DICOM, ISO TC215, OASIS, and IETF. I am also an active member of "Profiling" organizations: IHE, and HITSP.  I am most active in the security/privacy workgroups in these organizations, where we receive strange requests from the 'other' workgroups. These requests are a fragment of a security issue, but don't have enough information around the issue to make them actionable work items. Some of them are issues for which the organization already has a solution, such as Transport Layer Security (TLS). Some of them are simply "Security Theater".

The security workgroups decided to provide some guidance to the 'other' workgroups on how to appropriately design their standard with security-built-in. Security is about mitigating risk to Confidentiality, Integrity, and Availability. So we knew that our guidance would be an instruction set on how to do a Risk Assessment. We knew that the 'other' workgroups are made up of smart people that needed simply a little guidance, but knew that we needed to carefully craft our guidance so that it would be used. So, we wrote a "Cookbook" on the topic of  writing the "Security Considerations" section of their standard. A title that we figured would have people thinking we were giving them simple instructions, read "Cut-and-Paste", on how they should write their Security Considerations section. We know it is the most simple approach even if one must first do a risk assessment which is typically not seen as a 'simple' task.

The advantages of this approach are:

1. The 'other' workgroup must first describe the expectations of the environment that they expect their standard will be used. This includes describing the already available underlying security technology.
2. The 'other' workgroup uses the risk assessment tool to quantitatively prioritize the actual risks. Thus they focus on real risks, and can prioritize the most 'risky' issues. 
3. The 'other' workgroup will flow-down unmitigated risks to the next level of design. There are risks that can't be mitigated by a standards organization. These unmitigated risks should be documented in their standard, "Security Considerations", as risks that are identified but not mitigated. This list of risks can be picked up by the next level of design.
4. The 'other' workgroup has good documentation of issues that the 'security' workgroup should work on. The risk assessment is a clear communications tool that has the background and the risk well defined and prioritized.

These Procedures are now available at:

• HL7 version of the "Cookbook for Security Considerations" has a really good PowerPoint training package. This one has not yet been piloted, but there are a few projects that will be running this process. These pilot projects are closely associated with the security workgroup.
• IHE version of the "Cookbook for Security Considerations" has some good experience having used the tool on a set of profiles already. The risk assessments are not considered normative, but are archived so that they can be reviewed when the Profile gets revised. These risk assessment spreadsheets are useful reference when a new 'other' workgroup uses the tool.

In both cases, more has yet to be learned.

Three Security Concerns for 2010

One of the HIMSS groups that I participate in asked the members for their three security concerns for 2010. (This is what also caused Glen to write the text that I have as a guest blog: Accounting of Disclosure Challanges and Top Information Security Concerns).

1) Identity. Including Patient Identity, Provider Identity, and User Identity. Identity is important to make sure that we get operational access controls correct, patient-privacy-preferences correct, delegation correct, accounting of disclosures correct, oversight correct, etc.

• Patient The aversion to a federally issued identity is well known. I am amazed that we are the only country that can’t get over this, yet have so many federally issued identities. We don’t need a federally issued identity, but a federation of identities. This is a strong linkage between the various healthcare identities. There could be purpose-of-use views into this federation that forbids the viewing of identities that your purpose-of-use does not need access to. What is important is that this is a STRONGLY provisioned linkage. This is NOT an algorithm that evaluates two sets of demographics and ‘decides’ that there is a probability that they match. The act of entering a new identity and matching it to the existing identities must be done following only well documented process. Essentially I am worried that a fuzzy matching of patient identities will have too many false positives and false negatives. Patient’s lives are too important. Patient misbehavior is too valuable.
• User Identity. This is highly linked to the Patient Identity as they are often going to be ‘users’ in the context of a PHR. This is also highly linked to “Provider Registries” that can be used to find a provider for treatment. And this is highly linked to “Directories” that are used today in the operational setting to manage user accounts for healthcare applications as well as other business applications (yes healthcare is a business and users need to do things besides use the EHR). Again a Federated approach is needed. The reason here is different than for Patient Identities. There is already a federally issued identity for Providers, NPI. This does not address all the ‘users’ of a Health Information Exchange; that is the P and O in TPO. Further there are many ‘users’ in the Treatment side that would not be issued a NPI.
  Former Posts on the topic: Federated ID is not a universal ID 

2) Secure by Design. I am worried that there is such a rush to carry on with point-to-point links without thinking through the security and PRIVACY issues that this would raise. I participate in standards, profiling, and government initiatives because I want to build security into the architecture, not bolt it on later when success accidentally happens. I attribute this to the false perception that if we let the security guys in to the discussion up-front they will slow us down and make the system non-functional. There is very good excitement around the medical advantages of sharing healthcare information. The Security geeks must not be pushed aside; we MUST push our way back into the discussion. And when we push our way into the discussion we must NOT prove ‘them’ right. Designing in Security does not need to be a problem. Use a RISK based approach, and Keep It Simple and Secure (KISS).

Former Posts on the topic: IT security problems continue, What has HITSP done to protect confidentiality with a suite of implementable security standards,  Implementing standards takes time. 

• A sub-theme here is abuse of de-identification. This is a method of LOWERING risk, it does not eliminate risk. ONC to test re-identification of protected data, De-Identification is highly contextual, How Private can Electronic Information Ever Be?

3) Accounting of Disclosures. This very important part of patient-centered-healthcare needs to be discussed more than it is today. There are many bad ways to implement this, as in assuming that it can be generated on-the-fly ala a security log. I suspect that the requirements today are not even meeting the need, especially in the USA. I expect that over time this topic will morph into something far more useful to the patient and less frightening to the healthcare organizations. I expect that we will learn much from the likes of Facebook/Twitter/YouTube/etc, yet will also have our social norms educated. ATNA and Accounting of Disclosures, Patrick Pyette: The Case for Privacy Accounting

4) Privacy Policies. I put this one in at #4 of 3 because I have little faith that this is solvable in 2010. There are simply too many divergent views on Privacy Policies.  IHE took a brave move in creating BPPC, a profile that simply provided a basic framework for indicating that a patient has agreed to a policy. No details about the policy are given except for it's unique identifier. HL7 is now extending this concept with a mechanism to add variables to the policy so that the content of the policy can be customized by each Organization-Patient pair. This customization is going to take a while to work out. This will be useful, but will take another 5 years before one could say that it is mature enough to implement. Consumer Preferences and the Consumer, Opt-In, Opt-Out.... Don't publish THAT!, RHIO: 100,000 Give Consent.

IT security problems continue (Designing a Secure HIE)

A new articile “IT security problems continue” is one of many articles that seem to hint that Healthcare IT, EHR, PHR, and all of the Healthcare Internet are stalled because of IT Security Issues. Yet Nowhere is there an list of these Issues. This article points at a press release “Hacker Attacks Targeting Healthcare Organizations Doubled in the 4th Quarter of 2009 according to SecureWorks’ Data” by a security vendor “SecureWorks”.

Actually the security vendor press release is more informative than the ‘news’ article. The press release is pointing out that based on statistics that they have from their customers, attacks on healthcare have increased where others have not. This seems to indicate an intentional shift in the attacker community.

SecureWorks®, Inc., a leading global provider of information security services protecting 2,700 clients worldwide, reported today that attempted hacker attacks launched at its healthcare clients doubled in the fourth quarter of 2009. Attempted attacks increased from an average of 6,500 per healthcare client per day in the first nine months of 2009 to an average of 13,400 per client per day in the last three months of 2009. Attempted attacks against other types of organizations, protected by SecureWorks, did not increase in the fourth quarter. More

This vendor then goes on to advocate for “Defense-In-Depth”, and implementation of the kinds of services that they offer. All good ideas. What they don’t cover is some architectural solutions that can be put inplace.

The concern that people are having with Healthcare IT movement today is that this is an effort that will connect many healthcare organizations to each other. This connection can be done the way it is today with point-to-point solutions. This kind of a solution means that each connection between two organizations requires that one of them open up a hole in their defenses, and sometimes can mean both must open up.

The alternative architecture that I have been advocating for, due to my involvement, is the model around an XDS based HIE. In this model each healthcare organization will be making outbound connections to some common infrastructure, and only needs to have one inbound connection. There is a central set of services (Registry, PIX Manager, PDQ Manager, Audit Record Repository, Time Source, and XCA Gateways) that do need to be highly protected.

These central services are critical, but contain very minimal healthcare information as they are focused on different types of indexes and cross-references. In all cases IHE has also provided in the ATNA profile a way to highly-authenticate both sides of any connection and protect all communications. Any hacker would be incapable of this authentication step, so would not be able to attempt other secondary attacks like SQL injections. This is also true of the potential inbound connection to the healthcare organization to give access to the high-fidelity documents in the Repository (this could also be outsourced for the really small organizations).

As an architecture the XDS family has other Privacy and Security benefits that are beyond this core approach. These are nicely outlined in an IHE white paper on Security and Privacy in an HIE