Defining Privacy

Privacy is a very important Human Right, yet very hard to define. I am very encouraged by all the efforts in Healthcare on Privacy. These efforts are caused by the interest, yet made complex by the lack of a simple definition for Privacy. The problem with defining Privacy, even in Healthcare, is that there really isn't a single definition of Privacy. The reason is that Privacy has multiple dimensions. Controllership, Confidentiality, Accountability, Accounting, Correctness, Transparency, Disclosure, Consent/Authorization, etc. This is why Privacy is often described in terms of Privacy Principles. As the concept of Privacy is made up of all these various dimensions.

There are some standards that have definitions for Privacy

• ISO/IEC 2382-8:1998 -- Freedom from intrusion into the private life or affairs of an individual when that intrusion results from undue or illegal gathering and use of data about that individual.
• ISO 7482-2:1989 -- The right of individuals to control or influence what information related to them may be collected and stored and by whom and to whom that information may be disclosed.
• AHIMA -- The quality or state of being hidden from, or undisturbed by, the observation or activities of other persons, or freedom from unauthorized intrusion; in healthcare-related contexts, the right of a patient to control disclosure of protected health information.
• Countries like Canada -- (1) The claim of individuals, groups or institutions to determine for themselves when, how, and to what extent information about them is communicated to others. [Defined by uses this definition from A.F. Westin, Privacy and Freedom (1968). Basis for Privacy Act of 1974 (P.L. 93579; 5 U.S.C. § 552a).] (2) The right of an individual to live free of intrusive monitoring of their personal affairs by third parties not of their choosing.

I find that it is better to understand the Privacy Principles in order to understand what the term Privacy really means. See some of the foundational Privacy Principles. 

• The OECD (Organization for Economic Co-operation and Development) Privacy Principles are considered an utmost set of High-Level Privacy Principles because they are widely accepted, and they are the foundation of the European Union privacy regulations. 
• The “Privacy by Design” by Ann Cavoukian, Information & Privacy Commissioner of Ontario, Canada; Design principles are more targeted at task of systems design. 
• International Safe Harbor Privacy Principles 
• The USA Whitehouse consumer principles have been published just last year and therefore carry more modern wording and readability while still maintaining the same goals. 
• The philosophy highly influencing the Whitehouse that the consumer understands the context of their interaction Privacy As Contextual Integrity, Helen Nissenbaum 
• USA FTC – Fair Information Practice Principles 
• Etc – EC/EU, Canada, UK, AU, etc… 

The OECD  Privacy Principles are as good as any to review

1. Collection Limitation Principle --  There should be limits to the collection of personal data and any such data should be obtained by lawful and fair means and, where appropriate, with the knowledge or consent of the data subject.
2. Data Quality Principle -- Personal data should be relevant to the purposes for which they are to be used, and, to the extent necessary for those purposes, should be accurate, complete and kept up-to-date.
3. Purpose Specification Principle -- The purposes for which personal data are collected should be specified not later than at the time of data collection and the subsequent use limited to the fulfilment of those purposes or such others as are not incompatible with those purposes and as are specified on each occasion of change of purpose.
4. Use Limitation Principle -- Personal data should not be disclosed, made available or otherwise used for purposes other than those specified in accordance with Paragraph 9 except: a) with the consent of the data subject; or b) by the authority of law.
5. Security Safeguards Principle -- Personal data should be protected by reasonable security safeguards against such risks as loss or unauthorised access, destruction, use, modification or disclosure of data.
6. Openness Principle -- There should be a general policy of openness about developments, practices and policies with respect to personal data. Means should be readily available of establishing the existence and nature of personal data, and the main purposes of their use, as well as the identity and usual residence of the data controller.
7. Individual Participation Principle -- An individual should have the right:a) to obtain from a data controller, or otherwise, confirmation of whether or not the data controller has data relating to him; b) to have communicated to him, data relating to him within a reasonable time; at a charge, if any, that is not excessive; in a reasonable manner; and in a form that is readily intelligible to him; c) to be given reasons if a request made under subparagraphs(a) and (b) is denied, and to be able to challenge such denial; and d) to challenge data relating to him and, if the challenge is successful to have the data erased, rectified, completed or amended.
8. Accountability Principle -- A data controller should be accountable for complying with measures which give effect to the principles stated above.

It isn't even as simple as these 8 Privacy Principles. There are regional nuances, personal decisions, concerns for safety/health, etc. Often times there is complaints that these Privacy Principles get in the way of Medical Ethics  the actual cases of conflict are few and usually well understood by those affected.

So, you can see there isn’t one concept that makes up “Privacy”. Even Wikipedia has trouble simplifying it http://en.wikipedia.org/wiki/Privacy

Security Considerations: Healthcare RESTful Resource specifications

This topic came up last week at the HL7 meeting, that is, just how much should FHIR say about security. Those of us that have thought about this quite a bit, including many who have actually coded the RESTful services; come down on the side of : There is very little that the RESTful Resource specifications (FHIR, DICOM-WADO-RS, IHE-MHD, etc) should say, but they should recommend robust implementations that have wide potential use of the security layer built into the transport, specifically HTTP(S).

I recommend everyone that wants to help develop this to get involved in the IHE-IUA profiling effort. There is actually much to be said, but it can  be said in one place and re-used by all those that are working hard on making good Healthcare RESTful Resource definitions.

Shown pictorially as the RED layer

The Medium Length answer is… 

There is good stuff already available, use it

a) Use HTTPS to protect against most network risks (encryption, hashing, server authentication), with proper certificate validation including revocation checking
b) Have the ability to use Client Certificates on HTTPS to close the client side risks and identify the client system to the server, with proper certificate validation including revocation checking
c) Have the ability to leverage HTTP authentication mechanisms.
c.1) Internal to an organization the use of Kerberos (Microsoft Active Directory) is common. This is profiled in IHE as EUA
c.2) Between large organizations the use of SAML is a mature Identity Federation. This is mostly profiled in IHE as XUA, but needs to leverage the SAML-SSO-PROFILE from OASIS for browsers.
c.3) In cases where the user is more mobile, or less associated with a large organization, or simply using more lightweight systems, or where using third-party services/applications, or etc… This is the space that the IHE IUA profile is looking to fill. This profile likely will leverage oAuth 2.0; but it is in development now. (The subject of the e-mail that started this thread)
d) Audit Logging through either the FHIR SecurityEvent, or IHE-ATNA should be encouraged.

There are various other things that will come together after we get this far. Much of this advanced stuff is actually inside client or server and thus not needing to be exposed in a RESTful Resource specification (like FHIR). But some of the work we are doing now in the HL7 Security WG will impact user identities, data tagging, and obligations on release of data.

The longer answer, which is really the start of the security project:
The HL7 Security WG has a handbook published for HL7 Standards development that directs the standards developers on how to consider Security (and Privacy). http://wiki.hl7.org/index.php?title=Cookbook_for_Security_Considerations I will be using this process for FHIR, while at the same time doing it for IHE, DICOM, and others. Thus I intend on addressing many use-cases as I can.

I suggest we apply security/privacy in phases. Generally speaking there is little impact on FHIR in the first few phases, where applying Security in the Transport layer. For the vast majority of use-cases one simply plugs in common HTTP based security. Further the choices in HTTP based security can be done very late in the implementation phases with little impact on applications, provided they use mature HTTP stacks. Just like FHIR is leveraging as much as possible from common toolkits, we should do the same for Security.

But as we mature our use of RESTful Resources and fine-grained security we will need to get more involved. This because the more fine-grained security is not commonly used in non-healthcare REST use-cases. It isn't a total void either, so we will use existing standards. We just will eventually need to get more detailed. Much of this more detailed work is being modeled now in the HL7 Security WG. Ultimately we will need to define security-tags that could be carried on every resource, content encryption, partial encryption, non-repudiation, etc.

Consent Management
On a related note, but not completely off base, I would like to see a “Consent” resource, modeled off of a combination of the HL7 SOA Access Control Service, and the HL7 CDA Consent Directive. We should start basic. Not because it is hard, but because there are far more impactful risks to worry about first. Using risk assessment to guide our priorities.

Simple to Start
First, let’s focus on HTTP based REST. For most of the RESTful work going on now it is using HTTP, FHIR has visions of going beyond HTTP.  I am not trying to exclude the other models, just trying to have a coordinate analysis. The other transports that are envisioned for FHIR will be able to leverage much, but will also have some differences.

Initially one just deals with the high-impact risks to security, that is risks to “Confidentiality”, “Integrity”, and “Availability”. The high-impacting risks are easy to deal with in HTTP, one just applies HTTPS. Normal HTTPS doesn't deal with all of the high-impact risks, but is a foundational starting point. There are alternatives, but those alternatives usually come into a system when dealing with fine-grained risks and rights. For the sake of our efforts, lets start simple.

Encryption, Hashing, and Server Authentication
HTTPS is not without controversy, we should warn the users of FHIR that they should be careful about validating the server certificate. Normal browser behavior, and some HTTP toolkits, don’t do a good enough job here. Such as they don’t check revocation lists, they accept a far too wide list of Certificate Authorities, etc. This is a RISK that we identify, but don’t mandate any solution, as the solution would be a policy decision. But we do identify it as a risk and we do flow that risk down to the next level of design. This is a great example of what the Security WG recommends in the Security Considerations Cookbook.

Client  Authentication
I would like to also recognize the risk that the service side doesn't know what system is requesting the resource when simply using HTTPS (as HTTPS only authenticates the service, not the client). There are some alternatives. These alternatives are part of the IHE Internet User Authorization (IUA). Many of these alternatives are again totally transparent to FHIR as a specification, the more transparent we can make IUA the better. IUA is not trying to replace the most basic solutions.

High level alternatives (various combinations and effectivity)

1. Authenticate the system
2. Authenticate the software
3. Authenticate the user

Ultimately we are trying to figure out

1. If the transaction should happen, that is to test Access Controls
2. to record that the transaction was allowed or denied and why, that is to record Audit Log

Client System Authentication
Some will find the most easy solution is to use Client side Certificate Authentication. Called Mutual-Authentication, and the core protocol in the IHE-ATNA profile. This is technically easy, but administratively hard. If you are making a fixed number of connections to clients, this is likely a good choice. For example a corporate issued device that has controls on the device to assure it is secure, like persistent-memory encryption and the like. Easy to issue a certificate to these and be done. And when the device is lost/stolen the certificate gets revoked and magically it no longer has access.

Client Certificate Authentication is sometimes sufficient, sometimes too hard, sometimes unnecessary. Hence why it should not necessarily be mandated, although it would be highly recommended to be compatible and thus any implementation should have the capability.

Use-Cases
At this point we need to get more use-case specific. This is because dealing with the next level of granularity requires different pathways. From a high level we are speaking of two basic patterns. PUSH and PULL. Specifically these break down into the Client side Access Control and Audit Logging; vs the Service side Access Control and Audit Logging. At the modeling level you always presume these are happening at both sides. One models each side at a time. If either side is not satisfied that access should be given, then it stops the disclosure. Sometimes, like in the case of browser based applets, the client access control modeling is set to NULL.

Client Access Controls
Generally the client must make the access control decision sufficient for the client’s purposes, and record the audit log sufficient for the client’s purposes. Yes this can sometimes be NULL. I would simply point out that a Client that is doing a Create operation is choosing to expose the content of a Resource to a Server. This is usually the use-case that one focuses the client access control decision on. However this client side access control decision is totally within the client, and thus not exposed on the FHIR modeling. yes the server should also have a say in if it will keep it our not, but the disclosure has already happened by the time the Resource gets to the server.

Further down the line, we will look at how the Client can handle the case where the Access Control decision comes with ‘okay, with strings’, otherwise known in security circles as “Obligations”. For example, where the client Pushes content (message, publication of a document, RESTful Create), but the content has restrictions on use. Such as no-re-disclosure, for-treatment-purpose-only, no-persistence, etc. Same is true about a Server returning a Resource. The HL7 Security WG is currently modeling this in abstraction right now for future standards availability.

Server Access Controls
The Server will also do an Access Control decision, and record Audit Log events. This is where most of the attention is focused, and with good reason. Because most data accesses are in Request/Response pattern, and the Server is the typical place to restrict access. It isn't the only model, some systems trust their clients to do access control decisions and thus don’t make any at the server side. Some do access control decisions in various forms in both places (or more).

What the IHE IUA (oAuth?), XUA (SAML), EUA (Kerberos), and ATNA (Client TLS) do is try to explain how a client can encode claims about identity and context such that the server can interpret them. Interoperability is focused on both sides being able to use the information. In this case it is the system, application, and/or user identity that is being communicated in a security token. The server uses as much as it needs to use to come to a decision to release the information requested. The security system does need to understand sufficiently the content of the RESTful Resource so that it understands the information requested, but the Resource specification doesn't really need to understand the security system. The security system, when faced with not enough information to allow the data to flow, denies the transaction, usually by claiming the requested information doesn't exist (so as to not allow a malicious probing to determine existence vs non-existence of information)

Impact on RESTful Resources (FHIR, DICOM-WADO, IHE-MHD, etc)
The hope for IUA is to make it as transparent to the Resource definition as possible. I have heard this need. I understand the desire to not have any URL parameter modification, sometimes this can be done. There is already rather transparent solutions in IHE-ATNA (Client TLS), EUA (Kerberos), and XUA (SAML). The IUA use-cases are different, and useful.

There is definitely an impact on application architecture and programming. Leveraging a mature programming infrastructure helps, but clearly there will be responsibilities. These responsibilities and behaviors are out-side-the-scope of the RESTful Resource specification. For example in properly maintaining cookies, or maintaining an application-secret. The least impact is that the client must support HTTP redirects, and allow the redirects to interact with the user in some cases.

Conclusion
Any RESTful Resource specification should have minimal specification for Security or Privacy. Not because it isn't important, but because Security and Privacy are layers that are built into tools and layers that are designed to do their work transparent to the RESTful Resource specification. Very clearly impacting an operational environment, and having some impact on application development. 

What I would like to do is see how much of the above we can get agreement on. Once that list of capabilities is decided on, however small or large, we can start a Security/Privacy Risk Assessment. This will then show us what more we might need to do. Most of the time the additional risks are best handled in some design layer beyond the standards specification, so we simply document the risk in “Security Considerations” so that our reader is informed. But there are potential for risks that we need to hand over to further standards development.

See:

• IHE efforts in RESTful security
• Securing RESTful services
• SSL is not broken, Browser based PKI is
• How to Write Secure Interoperability Standards
• Identity Proofing and Authentication -- Patient vs Provider
• IHE mHealth Hackathon
• The Magic of FHIR – The HL7 movement toward REST resources, away from v3 and v2
• IHE Mobile access to Health Documents - Trial Implementation

Simplifying Security Audit Standards

There ARE Security Audit and Accounting of Disclosure Standards. I am constantly explaining why this is true. I blame History. Yes we used many standards organizations but we have coordinated the efforts so that they are already all in harmony

1. ASTM E2147 – Setup the concept of security audit logs for healthcare including accounting of disclosures
2. IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
3. DICOM Audit Log Message – Made the information model Normative, defined Vocabulary, Transport Binding,  and Schema
4. IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
5. NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
6. HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
7. HL7 FHIR - Defined a RESTful binding for the Security Audit Event, and thus provide a Query/Retrieve also
8. ISO 27789 – is defining the subset of audit events that an EHR would need 

There is very little about IHE-ATNA specification. These other standards are where the real stuff is. I am however happy to use IHE-ATNA as the marketing tag.

Community of Experts
I have been involved in developing Security Audit Standards for Healthcare since I started working on Healthcare Standards. Back then there were a handful of people working on Security and Privacy standards for healthcare. We tried to get more people involved, but the reality is that Security and Privacy is simply not an exciting space. I get it, i am a security geek, and we are few. I still only need two hands to count the people working on Security and Privacy standards in Healthcare. They are retiring about as fast as they arrive.

The Standards that we do have in Healthcare for  Security Audit all are well harmonized, because of the fact there are few people working on the domain. Even though we did the  work in very different standards organizations  It is the very fact that we did this work in many standards organizations that makes it hard to determine if we have Security Audit standards in Healthcare.

Abstract Model
The core standard that sets up the conceptual model comes from ASTM E2147. This defines the purpose of a security Audit Log, the uses of this audit log information, including how it is used to provide patients with accounting of disclosures.

This specification has been leveraged by many regional initiatives including in the USA the Meaningful Use Stage 2.

Data Model

We then needed to produce a schema that would meet ASTM E2147, and provide more specific guidance on how to describe that an event has happened. At the time there was much harsh competition between the various Healthcare Standards organizations. Again, not within Security/Privacy community. So we decided that ASTM was not the right organization to do this Data Modeling, and neither was HL7 or DICOM the right  organization. IHE couldn't be used as they only profiled existing standards. So we chose a non-healthcare organization. IETF was at the time a very open organization, so we chose to go there. Unfortunately for us, IETF changed their rules of publication while we were developing. Thus by the time we finished RFC-3881 we could only get it published as Informative. Thus it couldn't be used for conformance claims, it wasn't normative.

Normative Data Model We then needed somehow to get the data model and schema that we developed in IETF RFC-3881 to be normative. By this time the Healthcare standards organizations were behaving better. More importantly is that Radiology was using RFC-3881, so the Imaging world needed the  Normative schema more than other parts of Healthcare. So, we simply imported the RFC-3881 into DICOM and stamped it Normative.

Note that this did not produce a Audit Log Standard that was any different than RFC-3881, and this has nothing in common with any other  part of DICOM. So, implementing the Audit  Log Standard from DICOM does not require you  to implement anything else in DICOM. It is completely independent.

Now days DICOM isn't exactly the same as the original vision in RFC-3881, because mistakes were found and because functionality needed to be added. So, now days if someone starts with RFC-3881 they will end up with not the same thing. I just this week noticed two more things that need to be fixed.

The normative specification is ISO 12052 --- aka DICOM. It is freely available. Specifically you want Part 15 - Security and Systems Management. Specifically you want in that text Annex A.5 AUDIT TRAIL MESSAGE FORMAT PROFILE

Transport binding to SYSLOG
Both DICOM and IHE chose to leverage the SYSLOG standard. This is the standard that is used in general purpose IT to collect audit logs from various devices (Firewalls, IDS, Databases, Web-Servers). The SYSLOG protocol comes in two flavors. The general problem of event transport suffers from various risks for which there is no perfect solution. The UDP version of SYSLOG does fail from the risk that it will loose events when the number of transactions per second become very large, but it is far more simple and doesn't fail in other ways. The TCP version of SYSLOG assures that all events will get recorded, but does need to have buffer management handled and even here the  buffers can get overflowed. The TCP  version also supports security through TLS, so does address some confidentiality and integrity risks.

So essentially this gives us a SYSLOG binding using XML payload. I will point out that IHE-ATNA is really nothing more than bringing forward the DICOM specification into a Profile for visibility.

Query Function
Up to this point there is the  expectation that the Audit Record Repository is simply receiving all these events from various systems that are detecting and logging security relevant events. The expectation is that this system can have functionality to address Reporting, Alerting, Alarms, and such. This is product functionality. This functionality can be accomplished given the audit schema and the cooperation of all the systems logging events. The access control to this Audit Record Repository is also a very sensitive resource. This system has records retention requirements that are very hard to accomplish. The audit log record must be protected against many unintended and malicious risks. This is why there has been little developed in the space of Query on the Audit Log.

Query Service
HL7 PASS has produced a Service definition -- for what a Query might look like. This Draft Standard for Trial Use leveraged the very same Standards identified above. It simply added a Query and Retrieve transaction. This is now being looked at in HL7 to determine if there is really interest in further developing it. So far there has been little interest.

Security Audit Log on FHIR
The coolest thing to happen lately is that the HL7  FHIR project has take the same standards as above and created a RESTful resource out of them. This simple effort produces significant capability.

First, it is another way for an application to record that a security relevant event happened. HTTP is not a great protocol for this very chatty eventing (yes there are speedy solutions). Sometimes an application has easy access to RESTful technology and the effort to get more complex tooling will result in avoiding doing the audit logging completely. Thus we can accept that there is now an HTTP binding for recording an audit log event. I am not sure how this will be received at IHE, since IHE purpose is to reduce the number of ways to do one thing in order to converge on one method that everyone can implement with confidence. Adding HTTP binding could only be confidently used if all Audit Record Repositories implemented the service side.

Second, and more exciting, is that through the magic of REST there are now Query and Retrieve transactions on this same resource space. Yes this opens up a huge question of Access Control to these transactions. More risky is that REST also magically adds Update and Delete; operations that should never be allowed on an Audit Log. These risks are identified in the FHIR  specification. The security layer that IHE is working on with IUA should support these use-case needs.

Application Level Functionality
ISO TC215 is balloting right now ISO 27789  - Health Informatics - Audit Trails for electronic health records. This goes up  another layer and explains how one would apply the very same standards above to an EHR. This includes a set of use-cases that are supported. This is simply an application of the same standards to EHR technology.

The HL7 EHR-Functional Model has some of this, but not quite to the same level of detail. The expectation, I hope, is that they will leverage ISO 27789, thus carrying on the tradition of harmony.

Conclusion
Yes we used many standards organizations but we have coordinated the efforts so that they are already all in harmony

1. ASTM E2147 – Setup the concept of audit logs for healthcare including accounting of disclosures
2. IETF RFC 3881 – Defined the Information Model (IETF rule forced this to be informative)
3. DICOM Audit Log Message – Made the information model Normative, defined Vocabulary, Transport Binding,  and Schema
4. IHE ATNA – defines the grouping with secure transport and access controls; and defined specific audit log records for specific IHE transactions.
5. NIST SP800-92 – shows how to do audit log management and reporting – consistent with our model
6. HL7 PASS – Defined an Audit Service with responsibilities and a query interface for reporting use
7. HL7 FHIR - Defined a RESTful binding for the Security Audit Event, and thus provide a Query/Retrieve also
8. ISO 27789 – is defining the subset of audit events that an EHR would need 

Note there is very little in the IHE-ATNA specification. These other standards are where the real stuff is.

UPDATED: February 26, 2015 with direct links to the HTML version of the Audit Log Message.  A very readable and directly usable specification that does NOT require you to understand anything else in DICOM. Also the FHIR version of SecurityEvent (soon to be AuditEvent) is also compatible.

For More information

• Testing your ATNA Audit Log implementation
• MU Patient Engagement - Activity History Log
• Patient Data in the Audit Log
• IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
• Accountability using ATNA Audit Controls 
• ATNA and Accounting of Disclosures
• ATNA audit log recording of Query transactions
• How granular does an EHR Security Audit Log need to be?
• Document Submission: Audit requirements under error conditions
• ATNA + SYSLOG is good enough

IHE efforts in RESTful security

This is a simple update at the beginning of the year and IHE development cycle.

First, the slate of things that IHE IT Infrastructure (ITI) committee is working on this year is large. Here is a summary of the work items for the ITI  committee. I state this because last year ITI got one profile completed, the Mobile Health Documents profile that I wrote. So I want to encourage extra support from people who don't usually get involved.

The specific work item of interest is one that I am calling “Internet User Authentication/Authorization” (IUA). Yes, I am being cute with the acronym since there is already EUA and XUA. They are all very functionally similar, just focused on different technology stacks.

IHE ITI is right now in the stage of gathering use-cases and thus the 'interoperability needs’. In the coming months these needs will be evaluated against available standards. The most likely standard at this point is oAuth 2.0. Due to the scope and expected standard, this is more than just user authentication as it also includes application authorization. Much like the scope of oAuth. We are not purely driven by oAuth capability, but like oAuth the need is based on the use-case problems. The problems of Internet based Authentication and the problems of mobile devices and mobile applications.

This profile is expected to be used widely and not just include IHE use-case. IHE is gathering usecases from HL7-FHIR, DICOM-WADO, and Continua. This profile is also expecting to leverage work that has already gone on. For example the RHEx work done in the USA under the S&I Framework. This profile is also expecting to be in harmony with the efforts of the USA NSTIC effort.

The development work will be done through a Google+ community. This is an open community due to the interest from many organizations. The workspace for the development will be on the IHE FTP site 

There are two formal telephone conferences prior to the next face-to face. On 2/13 and 3/13 at 8am central. These are the more formal workitem focused with the whole ITI committee. Right now we have a weekly meeting Wednesday mornings at 8am central. However this is going to change. There will be some form of survey out to discover the best time.  This survey will utilize the Google+ community  so sign up. The IHE calendar is published at http://www.ihe.net/calendar/

The next face-to-face meeting for the IHE ITI committee is March 18-22, in Treviso Italy. This meeting is where we focus on finishing the  Vol 1 material, and doing the standards analysis. The result of this meeting should be the selection of a standard to develop.

IHE is an open and transparent organization, but in order to have voting privileges one must be a member in good standing. http://www.ihe.net/governance/index.cfm

IHE Encryption choices

IHE now has full coverage on how to Encrypt sensitive data.

The following table comes from the IHE-Document Encryption (DEN) profile. It was created in that supplement as a way to verify the need for the parts of the DEN profile. This table recognizes that IHE-ATNA already covers most of the encryption needs, especially network transactions. However there is a need for encrypting a single Document at a time, and for encrypting XDM removable media. These needs are covered in the DEN profile.

The following table uses a large “X” to indicate the best solution, the solution that is recommended and optimal for that use-case. The use of “(x)” is an indication of where there is support in a sub-optimal way; usually this choice is more complex and doesn't fully handle key management. Multiple solutions can be used as well. For example one can use Document Encryption, and also XDM media encryption.

Use-Case	Doc Enc (CMS)	XDM Media Enc (CMS)	ATNA (TLS)	ATNA (WS-Sec)	XDM Email option (s/mime)	PDI privacy option (CMS)
Point-to-point network exchange between machines	(x)		X	(x)
Network exchange between machines in different trust domains	(x)		X	(x)
Online exchange of documents where partially trusted intermediaries are necessary	X			X
Exchange of medical documents using person-to-person Email	(x)				X
Media data (DICOM) exchange between healthcare enterprises using physical media	(x)	(x)				X
Exchange health records using media	X	X				(x)
Media to media transfer	X	(x)
Patient Carried or Medical Records File clerk import	X	X
Unanticipated work-flows	X	(x)
Clinical trial	X	X
Multiple recipients of secure document	X	X
Sharing with receivers only partially known a priori, a group or a role	X	X				(x)
Partial encrypted XDM submission set	X

Note that there are other uses of encryption, but they fall outside the scope of Interoperability. For example there is Whole-Hard-Drive-Encryption, but in that case the same software that is encrypting is decrypting and thus there isn't an Interoperability need. Yes there still is a need to use good quality encryption algorithms, but this need is based on staying away from bad encryption algorithms, which is a standards issue but not an interoperability standards issue. Any whole-hard-drive-encryption solution will work just fine as long as it uses quality encryption algorithms. This is different than the need to have an interoperable solution for removable media, which the new DEN profile provides.

Additional Information

• IHE - Privacy and Security Profiles - Document Encryption
• Encryption is like Penicillin
• Critical aspects of Documents vs Messages or Elements
• Using both Document Encryption and Document Signature
• Document Encryption
• Securing RESTful services 
• Healthcare use of X.509 and PKI is trust worthy when managed
• SSL is not broken, Browser based PKI is
• Meaningful Use Stage 2 :: SHA-1 vs SHA-2
• Trusting e-Mail
• S/MIME vs TLS -- Two great solutions for different architectures
• Healthcare Provider Discoverability and building Trust