QIBA Profile Template Improvements - 2012

	A	B	C	D	E
1	Item	Issue	Proposed Modification	Rationale	Conclusion
2	#	What is the underlying need/problem/issue to address	How should the template be modified to address it [If there are examples where this has been done, reference]	What is the argument in favor of this approach (and optionally counter arguements)	Decide which proposals to accept/modify/blend

3	0	(How should the following modifications be rolled out?)	Update the template. For new profiles, follow the new template. For WIP profiles, allow committees to decide which agreed changes are rolled into their current draft and which are rolled into a subsequent draft. (Although they should add a note in the profile giving readers a heads-up that there will be some format modifications in the future)	Want to drive towards consistency but don't want to unnecessarily hold up committees moving through the process.	Agreed.Plan to send updates to the development committees.
4	1	How can we distinguish between Normative and Informative material? Blending them means the text gets large and unwieldy and the requirements can get lost. (Strong agreement on the need for separation)	Separate labelled sub-sections for “Discussion” (informative material that explains the terms, the affect that certain parameters have, etc) and “Specification” (normative requirements). [CT]	Implementers who want "just the facts" can focus on the specifications section. Subsections for this makes it easier to reference.	Agreed. And keep discussion first since it helps understand the reasons for the shalls.
5			Flag all normative statements with "shall". [CT]	It's easy to search for. Sentences are unambiguous. (DICOM and IHE do this).	Agreed.
6			Flag most/all normative material by putting it in tables. [FDG-PET] [CT]	Engineers like tables. They're easy to find, easy to read.	Agreed.
7				Some requirements are most simply stated as a sentence. Prefer tables, require "shall", require keeping normative material together, allow sentences.	Agreed.
8			Also consider a second flavour of the document which omits all the informative material for brevity. Might be a software feature.		Lets look into the mechanics of how this would work (e.g. "show/hide paragraphs" in Word/PDF, or generate "readers digest version" at publication time). Revisit when the mechanics are worked out.
9	1b	How can we distinguish between Normative and Validation material? (i.e. what you have to achieve vs how we will test to confirm that you have achieved it)	Keep the contents of Profile Details (Part 3) to the Normative Requirements and separate the validation procedures for measuring compliance into the Compliance section (Part 4)	It keeps Part 3 focussed on how each participant contributes to the performance of the Activity. Part 4 can be reused by vendor engineers for product testing, by QIBA for "quantathon" tests, by sites for acceptance or other validations, etc.	Agreed in principle. Continue exploration of the QC Activity described below.
10			Some of this gets into Who is responsible for validation and how it's carried out.
11			There is a basis for including a QC Activity. Need to be clear about differentiating what belongs in a QC Activity vs what belongs in a QIBA Compliance procedure.	Can have a QC Activity for the site calibrations. Probably don't need a separate Acceptance Testing activity. Don't need to tell vendors how to do pre-shipping QC but the site QC Activity will likely inform what the vendor chooses to do internally. Some sites have their system installed many years ago. Do we need a Qualification Activity that is focused more on performance (where QC is focussed on consistency) that could apply to new installs or in-place systems? Need to be careful to limit it to what is needed for the Profile to meet it's claim, not a general best practices for medical imaging/physics. Need to consider usage of vendor/device specific phantoms, and how those	Would benefit from further exploration of this to clarify as described.
12	2	How do we make clear which actor is responsible for each requirement?	Avoid passive voice (e.g. “The protocol name shall be recorded.”) in favor of making an actor the subject of most requirements (e.g “The acquisition modality shall record the protocol name in the image header.”) [CT]
13			Put all requirements in a table with an actor column. [FDG/PET]
14			Put the subject in the sentence. Add columns in the table for each actor involved and put an X on rows that are requirements on that actor. Would allow for sorting while maintaining readability.		Preferred - see what it looks like
15	2a	Sites may decide to re-assign or differently allocate the actor responsibilities. (e.g. some task is done by a radiologist at one site is done by a tech at another, and by a physicist at a third)	Add boilerplate paragraph noting that the assignments in the profile are the "baseline" and if the site chooses to delegate/re-assign, that is fine as long as they make sure all the steps/responsibilities are covered.		Agreed.
16	3	How do we distinguish between requirements on the vendor/equipment and the requirements on the staff?	Separate all requirements relevant to staff into Section III (Profile Details) versus requirements on vendor/equipment which is captured in Section IV (Compliance Section) [FDG/PET]
17			Include staff as actors. [CT]	All requirements are on actors. Inside each activity it is clear what the actions/requirements of each of the actors are and how they combine (and are necessary) to achieve the goal.
18
19	4a	How do we make the claim brief, but also detailed/accurate. We need to be clear about what users of the profile can expect to achieve, but the essence of the claim needs to be concise.	Start with a single claim statement, then follow with a paragraph listing the conditions under which the claim holds true. [CT]
20	4b	How should the claim be worded to link best to the groundwork and conformance?	(Look to metrology people for ways to accurately make the claim given the uncertainty – give them the current set of claims from the profiles in the different groups. They will want to see the data/groundwork on which it’s based). (Tutorial on claim building? Explain how this bears on patients/populations/studies) (Want it to be a clinically relevant claim (i.e. in terms of care for a given patient), but the statistics are closer to the science/groundwork) (Prediction/Confidence limits vs 2SDev) (Prediction is more important than confidence because we are using this to make decisions on given patients, not on populations?) (Conditions where the claim is valid)
21	5	What numbering scheme should we use for sections?	Use Arabic numerals for each level. And restart subsection numbering inside each section. [CT]	It’s a bit more natural to reference Section 2.3 than Section II.3.	Agreed
22	6	How do we separate/address/balance different national approaches/requirements? (e.g. Referring to “standard of care” is a varying baseline depending on where you are. There will also be different regulations etc to consider)	In terms of requirements, the IHE approach has been to try to get a "center-of-mass" specification that is acceptable to all participants. Where there are remaining details specific to a given country/region, that country/region can submit a "National Extensions" appendix which includes additional requirements for use in that country/region. The profile technical committee reviews and publishes such extensions. Also, the profile documents several use cases (variations of practice) which are all supported within the framework specified by the profile.	The profile establishes a standard approach over a wide area which means products and training materials can be widely used. The "extensions" provides a safety valve for differences that cannot be resolved. Although the variations cause extra work, they are minimized and it is clear what requirements apply in any given location.
23	7	How do we word/structure the specifications so they are familiar/understandable to a variety of implementers? If it differs too much from local terminology, there may be acceptance issues.	(Try for “neutral”/international terms and include a glossary)
24	8a	How do we make a “current” requirement that is practical, while still signaling what our “aspirations”/expectations are? E.g. the Acceptable/Target/Ideal	Include future/target requirements in additional rows which are shaded grey. And set the “acceptable” requirements so they are readily achievable today by the vast majority of sites/systems. [FDG-PET]	The future/target requirements format mirrors the Acceptable requirements format.
25			Describe the Acceptable in the Normative material and the Target/Ideal in the informative. [CT]	Separating Target/Ideal removes ambiguity over what the pass/fail criteria is.
26
27	8b	How do we "raise the bar" over time? (i.e. achieving continually higher levels of performance as technology and knowledge improves over time and is deployed)	Publish updated versions of the Profile (e.g. QIBA FDG-PET 2015 is harder to meet than QIBA FDG-PET 2012. Research sites might jump right on 2015, some clinical sites might continue at 2012 for a while)	It makes clear both the progression and the time period when a given set of expectations/technology were set.
28	9	How does a reader know about the (sometimes subtle) conventions we have adopted?	Expand Appendix C (Conventions and Definitions) to describe them in more detail, and add a note early in the profile directing new readers to Appendix C.
29	10	How do we normalize "QIBA terms" across profiles? E.g. Repeatability, Technical Variability, ...	Consider a common/boilerplate Appendix C
30	11	Where to insert items relevant to quality control of devices versus quality control issues relevant to the device in the imaging facility	QC relevant to device in factory is part of Section IV (Compliance) while QC items related to the device (and workflows) at the imaging facility in Section III - Profile Details, subsection 6. (3.6) [FDG/PET]	There may be different specifications for a device leaving the factory versus at acceptance and regular frequency followup in 'production'. Also, there are QC items relevant to the imaging facility and it's personnel which is not applicable to device Compliance.
31		How do we make "easy to read and do" Cookbooks for staff at sites that are performing a given Profile/protocol on a given patient	Set up a companion document. Could get into instructions on how to get patients to do things that are needed for the profile. Such details might appear in Informative material or not at all in QIBA Profile.
32		(Separation of Compliance process and individual patient process)
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100