Discovery Project Process – Early Design

SCOOP’s initial design and vision were developed during a “discovery project”, where we solicited needs and engineered requirements. This was meant to form the basis for subsequent development cycles and not meant to be a definitive set of requirements. That is, we will continuously test and revise our design assumptions as we move SCOOP forward with our network members.

Process Diagram

Key Informant Interviews and Focus Groups

Part of the needs gathering evidence and requirements for the needs of the network was to carry out a set of interviews with researchers and practitioners. Findings from these interviews were fed into conceptual designs and validated through focus groups

Environmental Scans

We examined existing primary care research network designs, focusing on electronic based networks. Also, we examined non primary care networks that may have taken related approaches. Multiple scans and searches were undertaken to see how people tackled, for example, distributed data management.


Networks can take many shapes, sizes and approaches. They can be top down, they can be bottom up. They can exist for a single reason or they can serve many. The vision was important so that we could start to come to a more common understanding of what this network and the infrastructure will be.

Prototypical Questions

One of the main roles of the network is to facilitate answering questions about practice or the change in practice (I.e. due to an intervention). We decided to shape our requirements around the questions and developed, over the discovery project, some prototypical questions / studies. The intent of these questions is to:

  • Act as the scenarios to drive rationalizing our requirements
  • Provide a reasonable range of questions to start with to test designs
  • To highlight to practitioners and researchers the kinds of questions that could be supported by the network as they decide about engaging.
The prototypical questions are an interesting way to define requirements.


The principles developed will drive out many of the requirements and will act as guide posts as we get into the details of the design and implementation. Principles are higher level and can be more easily shared with broader constituents than requirements.

Initial Architecture and Requirements

Based on our questions, principles, and testing, we began to sketch out early architecture and requirements that can drive out the first cycles of development. We are taking an agile approach to development and so needed an initial design to start working against (and refining). All elements are made with our current, limited knowledge and know that, through action and testing they may change. Also, factors from the environment may change our approach to specific aspects (e.g. the selection of clinical data standards).

Early Iterations

In our planning, we wanted to describe the functions and elements (including deployment scope) that we would consider for the early iterations, creating clear and early goalposts that repeatedly achieve several things:

  • test assumptions
  • show increasing value to participants
  • work out design challenges

Member checking

Member checking occurred throughout, through meetings with researchers and practitioners to test assumptions and confirm our principles.

Technically Test Assumptions

Like member checking, we tested several early assumptions early in the process to see if things were possible. For example, we had an end to end test of (limited) data coming out of an EMR and being used to answer a question. This was important to do early to reduce risk of moving too far down a design concept.

Leave a Reply

Your email address will not be published.


Recent Comments