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 provides 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 issues and considerations you should start thinking about. (Really. Don't skip the Guidance comment boxes)
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. New literature and evolving technology will also contribute to making it a bit of a moving target.
Plan and Conduct Groundwork Projects
This is where you figure out what the critical sources of variance are for your biomarker and what requirements you need to write to actually achieve the Claim.
Hey, how hard can that be? Seriously though, consult a biostatistician. It's hard to give general guidance for this.
During the groundwork and drafting process, keep in mind the three primary functions of a profile:
- tell sites what can be accomplished by following the Profile. ("Profile Claims")
- tell vendors what their product must do to state conformance with the Profile. ("Profile Details")
- tell user staff what they must do to state conformance so the Profile Claims will be realized. ("Profile Details")
Follow Profile Writing Guidelines
One of the hardest parts in drafting a Profile is figuring out what goes in, what to cut, and how to word things.
- Put requirements in the Specification tables
- Start each table requirement with the word "Shall"
- It promotes direct wording and makes it clear this is a requirement.
- Searching a document for Shall steps you through all the atomic requirements.
- Don't use "shall" outside of tables or procedures.
- Use active voice
- Passive voice makes it less clear who has responsibility for the requirement being met.
- State requirements bluntly
- Leaving ambiguity and wiggle room just makes conformance checking more confusing.
- List a single actor for each requirement
- 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
- If it doesn't contribute to achieving the Claim, don't make it a requirement
- Profiles are about performance claims, not general best practices
- Requirements that confirm assumptions underlying the claim, contribute to achieving the claim
- Understand the assumptions (including the statistical ones) that underlie the claim.
- 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.
- Don't repeat requirements in the Claim section
- State a requirement once.
- Worse, using different wording introduces conflicting loopholes and interpretations.
- Exception: Symmetric do-check requirements
- It is sometimes useful to do something, then a paired requirement to check the result.
- Avoid synonyms.
- If it's the same thing, use the same word.
- It makes it easier to search
- If you figure something out that's not here, tell the Process Committee