De-Identification Profile
0.0.1-current - ci-build International flag

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

Artifacts Summary

Contents:

This page provides a list of the FHIR artifacts defined as part of this implementation guide.

Behavior: Capability Statements

The following artifacts define the specific capabilities that different types of systems are expected to have in order to comply with this implementation guide. Systems conforming to this implementation guide are expected to declare conformance to one or more of the following capability statements.

IHE DeId Audit Creator

CapabilityStatement for DeIdentification Audit Creator Actor in DeIdentification Handbook.

This Actor is derived off of the ATNA Secure Application or ATNA Secure Node actor with ATNA ATX:FHIR Feed Option.

This Actor is derived off of the Basic Audit Log Patterns (BALP) Audit Creator recording rich audit log entries to ATNA.

Structures: Resource Profiles

These define constraints on FHIR resources for systems conforming to this implementation guide.

Audit Event for De-Identification at Source

Defines constraints on the AuditEvent Resource to record when a De-Identification happens at the Source. Note that a De-Identification event often impacts many different patients, so many AuditEvent resources need to be created so that each Patient is individually represented. This prevents leakage of other patients' that were also De-Identified at the same time.

  • Export event
  • subtype of deidentify or pseudonymize
  • shall have source of itself
  • shall have a source agent
  • should have a recipient agent(s) if known
  • may have user, app, organization agent(s)
    • combine with the Security Token pattern
  • should have the custodian that released the data
  • should have the authorizer that represented the patient (may be the patient)
  • shall have a patient entity
  • may have the consent that authorized the de-identification
  • may have the authorizing client token (saml, jwt, etc)
  • may have the set of data entity(ies)

Terminology: Value Sets

These define sets of codes used by systems conforming to this implementation guide.

Audit Event Subtype for De-Identification

Defines the AuditEvent Subtype for De-Identification events. This is used to indicate that the AuditEvent is specifically for a De-Identification event. The code is based on the ISO 21089 lifecycle code for de-identification.
Entity Type for De-Identification valueset

ValueSet Entity Type for De-Identification

Terminology: Code Systems

These define new code systems used by systems conforming to this implementation guide.

Entity Type for De-Identification

These AuditEvent.entity.type are related to De-Identification policy identification.

Example: Example Instances

These are example instances that show what data produced and consumed by systems conforming with this implementation guide might look like.

Audit Example of De-Identification at source

Audit Example for a De-Identification from source perspective
Audit Example of authorized Re-Identification at source

Audit Example for an authorized Re-Identification from source perspective