De-Identification Profile, published by IHE IT Infrastructure Technical Committee. This guide is not an authorized publication; it is the continuous build for version 0.0.1-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/IHE/ITI.DeIdHandbook/ and changes regularly. See the Directory of published versions

De-Identification Handbook Home

Official URL: https://profiles.ihe.net/ITI/DeId/ImplementationGuide/ihe.iti.deid				Version: 0.0.1-current
Draft as of 2025-08-22				Computable Name: IHE_ITI_DeId

This handbook explains the PROCESS for removing individually identifiable information from healthcare data. This includes de-identification, pseudonymization, re-linking, design considerations, techniques, and risks. The intended audience is IHE Profile editors and healthcare information technology implementers needing a guide for designing and implementing de-identification systems.

Organization of This Guide

This guide is organized into the following sections:

1. Introduction to This Handbook
2. De-Identification, Pseudonymization, and Relinking
   • Navigating the Complexity of Privacy Concepts
   • Identifiability
   • ​Pseudonymization, De-Identification and Anonymization Explained
   • Overall De-Identification Approach
   • Definitions
   • Re-identification
   • Threats & Attacks
3. Data Types
4. Algorithms
   • Redaction
   • Fuzzing
   • Generalization
   • Longitudinal Consistency Constraints
   • Recoverable Substitution
   • Text Processing
   • Pass-through
   • De-identification datatype/algorithm matrix
5. Process
   • Step 1 – Requirements Design
   • Step 2 – De-identification Design
   • Step 3 – Design Validation
   • Step 4 – Implementation
   • Step 5 – Implementation Validation
   • Step 6 – Periodic Review of Implementation
6. De-Identification and Pseudonymization for IHE Profile Editors
7. Security Considerations
   • Design of De-Identification Algorithm
   • Execution of De-Identification on Data
   • ATNA and Other Logging Considerations
8. Exemplar
   • FHIR Examples
   • DICOM Examples
   • HL7 2 Examples
   • Family Planning
9. Other
   • Download and Analysis
   • Significant Changes and Issues
10. References

See also the Table of Contents and the index of Artifacts defined as part of this implementation guide.

Conformance Expectations

IHE uses the normative words: Shall, Should, and May according to standards conventions.

Must Support

The use of mustSupport in StructureDefinition profiles is equivalent to the IHE use of R2 as defined in Appendix Z.

mustSupport only has a meaning on items that are minimal cardinality of zero (0), and applies only to the source actor populating the data. The source actor shall populate the elements marked with MustSupport, if the concept is supported by the actor, a value exists, and security and consent rules permit. The consuming actors should handle these elements being populated or being absent/empty. Note that sometimes mustSupport will appear on elements with a minimal cardinality greater than zero (0), this is due to inheritance from a less constrained profile.