Upcoming Series: Implementing De-identification
An Enterprise Implementation Guide
Purchasing de-identification software and training staff to use it is a good first step – but more is needed to implement de-identification effectively. De-identification business architecture helps to clarify the goals, constraints, and scope of de-identification within the organization, to define necessary roles and functions, and to integrate it into the organization’s overall business process.
The importance of de-identification – the anonymization or pseudonymization of personal information shared for secondary purposes – is increasingly being recognized in the public and private sectors. Several high-profile privacy breaches in the past year have demonstrated the urgency of securing citizens’ personal information. De-identification plays a key role here, by creating datasets that pose a very low privacy risk and can fulfill many of the purposes for which personal data is currently used and shared. De-identification is becoming a necessity for organizations that manage, use and share large volumes of personal data, in fields as diverse as health care, finance, government services, and retail. Many organizations are developing policies related to de-identification, purchasing de-identification software and training staff in its use.
While these are important steps, alone they often do not lead to the effective use of de-identification. Organizations encounter a variety of problems when attempting to implement de-identification in a systematic way. Policies may not establish clearly who is authorized to approve or deny data requests, and on what basis. Management may lack necessary knowledge about appropriate risk management practices. Intended clients for de-identified data may not be aware of what types of data could be made available to them or how to request data. De-identified data prepared for clients may not suit their needs or timelines.
For organizations that are likely to use de-identification on a regular basis, it makes sense to design business architecture around de-identification. Business architecture defines the goals, scope, roles, and process for de-identification, ensuring that it is used with clear purposes and rules, integrates smoothly into the organization’s business process, and actually is useful to clients.
Over the next few weeks, we will be publishing a series of posts describing crucial steps for implementing de-identification in a systematic and risk-informed manner, based on our experience with large organizations seeking to develop de-identification services. Stay tuned to hear more about how to make de-identification work for you.
Table of Contents
Part 1: Who gets what kind of data?
Part 2: How mature is your de-identification practice?
Part 3: Designing de-identification business architecture
Part 4: How to choose de-identification software
Part 5: From planning to action to automation