Loading...
De-IdentificationOpen DataTransformation

Implementing De-identification III: Designing De-identification Business Architecture

De-identification business architecture aims to ensure that de-identification is used with clear purposes and rules, integrates smoothly into your organization’s business process, and is genuinely useful to clients.

The first two posts in our Implementing De-identification series describe initial planning steps for organizations seeking to implement de-identification effectively. Defining use cases establishes who will be receiving de-identified data and what types of data they will be able to access. Assessing the maturity of your current de-identification practices makes it possible to set targets for improved business processes, risk management, and implementation. The information gathered and goals set during these steps provide a base for the design of business architecture, which defines in more detail the goals, scope, roles, and process for de-identification.

Designing business architecture is basically about envisioning how de-identification could be implemented most effectively in your organization. This begins with a detailed needs analysis, which will include the perspectives of prospective internal users, data sources and clients for de-identified data. Existing data sharing contracts and the needs that they reflect should also be examined. By analyzing the defined needs and considering how to manage scope, cost, time and resources, you can confidently move forward with a plan for a de-identification service that makes sense in your particular context.

To design appropriate business architecture you will need to answer the following questions:

  • What are the needs of each group of prospective clients for de-identified data?
  • What existing data sharing contracts do you have and how do they affect the requirements for a de-identification service?
  • Will the service be located internally or outsourced? Who will have authority and accountability for it? Who will be responsible for carrying out the work?
  • How will the service contribute to the organization’s main services? How will it work with other services? How will it fit into the overall business process?
  • How does the service align with other projects? How does it integrate with other IT projects?
  • Which standards will the service follow? Who will provide privacy and security oversight? What will the service’s developmental lifecycle be?
  • How will the data model be structured? Will individual-level or aggregate data be collected? Will data be de-identified at the point of collection, or will a centralized de-identification service perform this task?
  • How will the service be funded? Is there enough interest in the service for it to be financially viable?

A particularly important task at this stage is to define the specific staffing component of de-identification. In order for a de-identification service to enforce best practices and engage staff in implementing changes, it should ideally be positioned at a senior level within the management hierarchy. Successful management of de-identification depends on the authority and effectiveness of two key resources:

  1. De-identification Practice Specialist: The De-identification Practice Specialist provides expertise on tools, techniques, and methodology. He or she is responsible for training staff in new practices by developing FAQs, providing a library of de-identification resources, and offering workshops. He or she also oversees risk management practices, develops de-identification templates for different data sharing scenarios, and creates and interprets risk reports for data releases.
  2. De-identification Service Manager: The Service Manager is responsible for understanding the dependencies and relationships between different data recipients, data suppliers, and the service. He or she must have a high level understanding of all current projects and their timelines, milestones and targets in order to realize the collective benefit of the service. He or she will also report on the maturity of de-identification methodology as it is implemented throughout the service.

A frequent risk to the overall implementation of a de-identification service and the specific staffing component is staff aversion to culture change. The consistent support of upper management is critical to the success of the service. It is the role of the De-identification Practice Specialist and Service Manager to facilitate proper training and maintain employee confidence in the service in order to ensure full acceptance and lasting integration into your organization’s practices.


 

In summary, de-identification business architecture will clarify:

 

  • Who will be using the service and what their needs are
  • Where and how de-identification services will fit within the organization and business process
  • Who will be performing and overseeing de-identification
  • How data will be collected, de-identified and released
  • How privacy and security requirements will be defined, implemented, and monitored
  • How services will be evaluated and continuously improved

Essentially, designing business architecture involves exploring and planning how de-identification can be implemented most efficiently and effectively in your particular context. This initial work makes it possible to avert many of the difficulties of launching a new service, and ultimately pays off in the form of a more efficient de-identification process, greater staff acceptance, lower privacy risk, and better client service.

Stay tuned for our remaining posts on selecting appropriate de-identification technologies and planning the rollout of de-identification services.

%d bloggers like this: