A Case for De-identification Business Architecture

Purchasing de-identification software and training staff to use it is a good first step – but more is needed to build an effective de-identification service. De-identification business architecture helps to clarify the goals, constraints, and scope of a service, to define the roles and functions it requires, 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. Many organizations which manage large volumes of personal data 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. Staff responsible for de-identification may be unsure as to who is authorized to approve or deny data requests, and for what reasons. Intended clients for a de-identification service may not understand the opportunities offered them. De-identified data made available to clients may not suit their needs or timelines. Before implementing de-identification, designing business architecture around it ensures that a de-identification service will have a clear purpose and rules, will integrate smoothly into the organization’s business process, and actually will be useful to clients. Business architecture defines the goals, scope, roles, and process for de-identification and lays the groundwork for a more efficient, economical, and transparent service. Building business architecture involves three major steps: first, locating the service within the organization, followed by defining the structure and function of a de-identification service.


Whether in business or in government, a new initiative will go nowhere quickly if it is not well-situated within the enterprise. Before a de-identification service is developed, a few parameters need to be decided:

  • How will the service be funded? Is there sufficient stakeholder interest for it to be viable? How will a vendor or vendors be engaged?
  • Where will the service be physically located? Who will have authority and accountability for it? Who will be responsible for carrying out the work?
  • How does the service align with other projects? How does it integrate with other IT projects?
  • Which standards will the service follow? Are there plans for privacy and security? What will the service’s developmental lifecycle be?
  • How will the service contribute to the organization’s main services? How will it work within other services? How will it fit into the overall business process?


Most architects would agree that the best designs are those that tap into the natural potential of their sites. As with physical architecture, business architecture ideally considers both its context and the needs of those who work within it. Its structures, functions, and processes have to fit well within the organization and serve staff and clients efficiently. The answers to the following questions will form the basic business architecture of the service:

  • Who needs de-identification? What are the needs of each group of users?
  • What is the business context of de-identification? Who will supply de-identification services? Which vendor(s) will be involved? Who will govern the program?
  • What services will be provided? How will these match the needs of specific client groups?
  • How will the data model be structured? How will data relationships be integrated?


Once a basic structure is established, the necessary systems within it can be designed. In this step, we move from structure to process – from organization to operation. The answers to the following questions will establish how the planned structure will function:

  • What is the service delivery model – who will handle client interactions?
  • What will the business process model and business function model look like? How will services be structured? What is the service process? What roles will be involved?
  • How will the performance of the service be measured and improved?
  • What are the business rules – that is, how much access to data will various clients and administrators have?

Working out the answers to these three groups of questions requires the time and involvement of a number of stakeholders. However, designing business architecture prior to the adoption of de-identification ensures that a service will be efficient and effective from the start, rather than developing through a costly process of trial and error. By defining the location, structure, and function of de-identification within the enterprise, business architecture guides the creation of a useful, well-organized, and well-governed service that enables increased data sharing while maintaining high privacy standards.