De-Identification Profile
0.0.1-current - ci-build

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

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. This Actor is involved in the generation of De-Identified data, and thus would record De-Identification Audit Events Ths Actor may be involved in events that uncover a Privacy Disclosure, and thus would record Privacy Disclosure Audit Events.

### 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
Ex-Patient-1-for-secondaryUse-pandemnicIPS-stage-0 |
Ex-Patient-1-for-secondaryUse-pandemnicIPS-stage-1 |
Ex-Patient-1-for-secondaryUse-pandemnicIPS-stage-2 |
ex-Bundle-secondaryUse-pandemnicIPS-example-patient-1-stage-0 |
ex-Bundle-secondaryUse-pandemnicIPS-example-patient-1-stage-2 |
ex-DeathCertificateDocument-Bundle-pandemnicIPS-example-patient-1-stage-1 |