Security Considerations

This text taken from the formal White paper.

All new IHE Profiles are required to have a Security Considerations section. This section communicates security concerns that the implementers need to be aware of, assumptions made about security pre-conditions and, where appropriate, key elements of a risk mitigation strategy to be applied. Historically, IHE Profiles have not addressed security considerations and thus implementers have had no direction. This document helps IHE Profile writers complete the Security Considerations section of their IHE Profile.

The Security Considerations section of an IHE Profile is intended to help implementers make a security assessment of their product / information system in relation to implementing an actor in that profile. It is not a thorough standalone security assessment. The Security Considerations section of an IHE Profile should only deal with issues specifically relevant to the interoperability provided by the profile and not try to encompass every security aspect of the use cases identified in the Profile in Volume 1.

---

3 How to write a Security Considerations section

Though the risks and mitigations table (presented in Section 2) contains necessary security steps and should be available to product developers and product implementers, it is too detailed to be included in IHE Technical Frameworks. The following sections will provide guidance as to how to integrate the outcome of a risk assessment into an IHE integration profile.

3.1 What should be integrated in IHE Technical Frameworks

When writing an IHE profile, you should focus on the relevant risks and how they have been addressed. The security section should be a literary presentation of the security constraints (e.g. mandatory or optional grouping with IHE security profile), the security features as well as a summary of the reasons why these constraints and features are required (risks addressed). It should also include a summary of the risks left to be mitigated by developers and implementers.

There is no right way to write a security section; you can organize the section as you see fit as long as all the relevant risks are accounted for and the corresponding mitigations are explained. As an example of what and how to integrate in the security section, see section 17.5 of the RFD profile.

3.2 Where to integrate security in IHE Technical Frameworks

Specific sections are devoted to security in the IHE supplement template. The section in volume 1 is for risks and mitigations that are profile-wide whereas the sections in Volume 2 are for risks and mitigations that are transaction or content specific.

Mandated or suggested grouping of actors with IHE security profiles should be presented in volume 1 with the other possible grouping necessary to the profile.

It may happen that, for historical reason, there is a common security section in the Technical Framework your supplement will be integrated in (either for the whole Technical Framework or for a grouping of profiles in which you profile will be), the security section in your profile should then only deal with risks and/or mitigations that haven't been assessed in the existing section yet. Even if such a section exists and seems very comprehensive, the preparatory steps presented in section 3 should nevertheless be followed to be sure nothing has been overlooked.

Finally, some specific security features developed during risk mitigation could turn out to be new functionalities for your profile. If such, they should be described within the profile as any other functionality, but should be referenced by the security section.

For example, risk on patient privacy led to include a de-identification function in the Teaching File and Clinical Trial Export profile (TCE) which is included as a function in the profile outside of the security section.