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.

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)

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.

ValueSet Entity Type for De-Identification

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

Audit Example for a De-Identification from source perspective

Audit Example for an authorized Re-Identification from source perspective

The following bundle reflects a complete death certificate record, including:

• the decedent demographics, including death date/time,
• their next-of-kin demographics,
• coded cause of death information,
• coded usual occupation and associated usual industry,
• death pronouncer,
• death certifier,
• funeral home information, and
• burial information.

In addition to pseudonymizing the Decedent Identifiers and Patient name, we are also applying pseudoidentifiers and names for the:

• Decedent Mother
• Decedent Father
• Decedent Spouse

The indirect identifiers in this record will be addressed during stage 2 de-identification.

The following bundle reflects the sample mortality data after applying the approved de-identification methods to the pseudonymized bundle as described in section IPS Data Element Mappings (FHIR). This shows:

• Date shifting throughout the bundle (applies to the date of death), and
• Data omissions, noting the data is omitted in emptyReason as ‘withheld’ at the section level, and as ‘masked’ in dataAbsentReason at the data element level.

The majority of the death certificate is redacted leaving the remaining data deeded for the study:

• coded cause of death
• coded usual occupation and associated usual industry,
• pseudonymized decedent demographics, including date/time of death

The Origional FHIR Document provided by the health Data Holder. The following bundle provides an example view of a record that could be in the research cohort for the pandemic patient. At this stage (0), there have been no alterations to this original record.

The following bundle provides an example view of the sample patient record after applying pseudonymization. This shows:

• A pseudo-identifier has been applied to the patient resource and replaces the original patient identifier throughout the document.
• A pseudo-name has been applied to the patient resource and replaces the original patient name throughout the document. Note that a pseudo-name is required as content is not permitted to be omitted or replaced with a null flavor in FHIR patient resources.
• Birthdate has been date-shifted forward by 107 days.

The following bundle provides an example view of the sample patient record after applying the approved de-identification methods to the pseudonymized bundle as described in section IPS Data Element Mappings (FHIR). This shows:

• Date shifting throughout the bundle (e.g. dates associated with problems, procedures, medications, immunizations, allergies, etc.)
• Data omissions, noting the data is omitted in emptyReason as ‘withheld’ at the section level, and as ‘masked’ in dataAbsentReason at the data element level.