How to Write a Profile

Congratulations, you are an author, editor or contributor to a new QIBA Profile. This is much like being a parent (including the "terrible 2's" and those rambunctious teenage years), challenging but rewarding. Also, it does indeed "take a village" to raise a new Profile. A diverse body of expertise is needed to nail down the intended clinical use cases for the biomarker, decide on an appropriate technical performance target, determine the key sources of variability that affect the performance, and draft clear requirements that eliminate, compensate or characterize each of those sources of variability. You will need radiologists, physicists, bio-statisticians and engineers at the least.

• Review the basic QIBA Concepts

These are terms and ideas that will be referred to throughout the rest of this.

• Review the QIBA Profile Template

The template should provide a sense of the content you will be developing. Don't skip the Executive Summary, which highlights the structure, and read the Guidance comment boxes, which describe some of the issues and considerations you should start thinking about.

• Review the Claim Guidance

The Biomarker Performance Claim is the anchor of the Profile. The remainder of the profile is the Requirements necessary to achieve the claim, and the Assessment Procedures necessary to test the requirements.

As you will see in the Claim Guidance, coming up with good Claim(s) is not trivial. Expect it to be an iterative process as your experience doing the groundwork and drafting the profile gives you a better appreciation.

• More steps involving Groundwork Projects etc <to be continued>

• Review Rules of Thumb for Profile text

One of the hardest parts in drafting a Profile is figuring out what goes in, what to cut, and how to word things.

• If it doesn't contribute to achieving the Claim, don't make it a requirement

• Profiles are about performance claims, not general best practices
• "Make the irreducible basic elements as simple and as few as possible" but not simpler/fewer. (Einstein)

• If you would not fail someone for not conforming to the requirement, then drop the requirement.
• Dropping requirements is fine but make sure you revise your claimed performance accordingly.
• Put requirements in the Specification tables

• The Discussion section is for additional information but can be skipped by folks who just want the requirements; hiding additional requirements there would be sneaky.

• Start table requirements with the word "Shall"

• This avoids passive voice. Passive voice makes it unclear who is responsible for the requirement.

• Don't use "shall" outside of tables or procedures.

• Shall is for requirements. If it's a requirement, put it in a table. If it's not a requirement, don't use shall.

• List a single actor for each requirement

• It needs to be clear who is responsible for the requirement being met. You don't the requirement unmet because two people both thought the other was taking care of it
• The Profile doesn't care HOW the actor gets it done, and if they explicitly delegate it or hire someone that's fine, but if it's not done the Actor is responsible.
• The Profile doesn't care if one human takes on multiple roles. In a given hospital the same person may take the role of both Radiologist and Image Analyst.
• Some profiles add notes in the discussion to clarify these details.

• For each requirement, consider how you would assess conformance

• If assessing conformance is obvious and will be done consistently, that's fine.
• If it requires a specific procedure, add the procedure to section 4 and reference it.
• If it's practically unassessable, then it's not a useful requirement so drop it