How to Write a Profile

From QIBA Wiki
Jump to: navigation, search

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.

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 they must implement in their product to state compliance with the Profile. ("Profile Details")
  • tell user staff what they must do for the Profile Claims to 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.

Keep the following in mind when drafting the Profile. Look at these again when reviewing the Profile for publication at any Stage.

  • 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 in Discussion would be sneaky.
  • Start table requirements 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.
  • Sentences with "must, has to, needs to" are not requirements so don't confuse readers by using those words.
  • Sentences with "should, could, might, etc." are also not requirements but may be useful to provide informative recommendations.
  • Don't use "shall" outside of tables or procedures.
  • Shall is for requirements. If it's an activity requirement, put it in a table. If it's not an activity requirement, don't use shall.
  • Use active voice
  • "Physicist Shall record the date/time of QC procedures." rather than "The date/time of QC procedures shall be recorded."
  • Passive voice makes it less clear who has responsibility for the requirement being met.
  • State requirements bluntly
  • Conformance is clearer/simpler/cheaper if it is binary; you either do or do not ("there is no try" 05.04).
  • Leaving ambiguity and wiggle room just makes conformance checking more confusing.
  • Don't feel bad about systems/sites that fail conformance. They're no worse off then when they started; they may still be useful, they just cannot rely on achieving the claim.
  • List a single actor for each requirement
  • It needs to be clear who is responsible for the requirement being met. You don't want 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
  • 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)
  • 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.
  • It doesn't have to go away completely. You can keep it as a suggestion in the Discussion if it's helpful.
  • Dropping requirements is fine but make sure you revise your claimed performance accordingly.
  • If dropping it leaves a source of variability in play, then your test data and the performance estimates should incorporate that variability.
  • If the Claim cannot be achieved with the stated requirements, you need to tighten the requirements or loosen the claim
  • Don't repeat requirements in the Claim
  • The claim is already contingent on conforming to the requirements; restating requirements in the caveats of the claim is redundant.
  • State a requirement once.
  • Stating it twice means you have to remember to revise the text in two places each time you change it.
  • Worse, using different wording introduces conflicting loopholes and interpretations.
  • Avoid synonyms.
  • If it's the same thing, use the same word.
  • Don't refer to the workstation, the Image Analysis Tool, the measurement software, and the Analyzer if it's all the same thing. Pick one.
  • It makes it easier to search
  • If you use different words, you make people think there is a subtle but meaningful difference and they may invent one.
  • These are just some guidelines we've figured out so far. Rome wasn't built in a day. Actually they've never stopped building it. So we start living in it and improve it as we go.

Further Reading

Consult the QIBA Process pages. And let us know what information is missing so we can add it to our ToDo list.