Groundwork and Profiling

From QIBA Wiki
Jump to: navigation, search

Concepts

A Profile is an implementation guide. A Profile defines a problem and tells each participating system what it must be capable of doing, and how it must be capable of interacting with the other systems in the profile to solve the problem.

IHE has proven Profiles to be an effective method for getting sophisticated solutions implemented and tested in products. QIBA goes beyond IHE in the need for an additional layer. Research and validation, referred to here as Groundwork, is necessary to understand, quantify and prove some of the underlying assumptions and details.

Groundwork is intended to answer Precursor Questions so we can write Profile Details. The Precursor Questions should tie the Groundwork activities to the Profiling activities.

Proposed Groundwork activities should each answer one (or more) clearly stated Precursor Questions. If we can’t identify a clear Precursor Question being answered, we should reconsider that Groundwork activity.

Precursor Questions should each be associated with a Profile Detail we need to specify or a Profile Claim we need to prove (also known as “requirements traceability”).

Think of Profiles as making Profile Claims of what users will be able to do; and Profile Details are what we specify participating systems and people must be able to do if the Profile Claims are to be achieved.

Groundwork which does not answer Precursor Questions, or Precursor Questions that don’t support Profile text can be moved down the “to do” list until we clarify what they’re accomplishing.

Profile Claims may also provide a useful linkage/entry point for regulatory groups. Awareness and involvement of groups like FDA may help align or flesh out the groundwork supporting certain profile claims such that the data collected can more effectively support FDA evaluations, accelerating the approval process and perhaps reducing some of the effort otherwise spent duplicating such work.

Profiles, Precursors & Groundwork – A Strawman

The following table is intended to help visualize the relationship between our activities, which in turn helps us plan/organize/prioritize/schedule those activities.

  • We can identify cells we choose to address in “this cycle” and set some target deadlines.
  • We can identify other cells as leading candidates for “next cycle”.
  • Some groundwork will be on the critical path to an early profile.
  • Other groundwork will be critical to a profile we plan to do in the future, but is not critical yet.
  • Some work will take a while so we may choose to get certain “future items” started now.

First Three Profiles: A Progression

For the sake of argument, the table is based on a sequence of three progressively ambitious Profiles. Each builds on the previous, each provides some useful capability, and each provides tools which will accelerate validation of the next.

Briefly:

1. QIBA CT Volume Quantification Profile - claims to let users perform, store, exchange and analyze specific spatial measurements on acquired images.
2. QIBA CT Tumor Volume Change Profile - claims to let users determine tumor volume changes to a certain level of accuracy across multiple acquisitions.
3. QIBA CT Tumor Response Profile - claims to let users evaluate tumor “response” to a certain degree of confidence.

There seems to be little preventing us from doing the first Profile now. The second requires more groundwork done first, and the third is even further down the road. Deploying the first profile would make it easier to do the Groundwork for the second and third.


Strawman Alert: Constructive criticism is encouraged. All this is open to discussion. The table is far from complete and is largely off-the-top-of-the-head.

The contents of the Table are drawn (a bit haphazardly) from Validation Plan and QIBA Process documents.

In a loose sense, the Profiles are an incremental breakdown of the grand endpoint in the Strawman Matrix; the Precursor Questions should reflect the Strawman Matrix Challenges, and the Groundwork and the Profile Details should reflect the Mitigation Strategy/Action Items.

Work can happen in parallel. A number of Groundwork activities will be going on at the same time. Profile writing can start now and doing so will uncover additional Precursor Questions. Profile sections can be sketched in and revised as the Precursor Questions are answered. We may find that some sketched sections are sufficient as they are and that Precursor Question can be deferred til later. We may realize that some Profile Details are not necessary to achieve the Profile Claims. We may realize that additional Profile Details are necessary to achieve the Profile Claims.

<<Either convert the table to Wiki format here, or insert a link to the Word document>>


Even if we are not publicly releasing the Profiles early on, this approach should keep activities closely tied to practical implementations.

The Profile Details have started to introduce the idea of specifying activities (things a system must be capable of doing itself, e.g. making certain measurements or performing a certain calibration) and specifying transactions (things one system must capable of conveying to another system).