DEFINITION:<br/>A collection of activities for the purpose of obtaining images of the subject, including purpose and objectives, and a description of the appropriate equipment characteristics, subject preparation and positioning, anatomical location, functional conditions, acquisition and reconstruction techniques and other parameters.<br/><br/>EXAMPLE(S):  <br/>CT of chest/abdomen/pelvis for oncology follow-up, using intravenous and oral contrast, with the subject positioned supine with arms up, in helical mode with tube current modulation, with single breath hold during entire scan, reconstructed in 2.5 mm thick slices using soft tissue and bone algorithms.<br/><br/>OTHER NAME(S):<br/><br/>NOTE(S):<br/>This class combines the common concept of an imaging protocol underlying the DICOM Defined and Performed Acquisition and Reconstruction Protocols.<br/><br/>In modeling, often the same term is used to mean different things and a single concept can have more than one name.  In the healthcare arena, the term "protocol" is somewhat overloaded and must be qualified to provide semantic context.  Therefore during the early years of the BRIDG project, the term "study protocol" was chosen to disambiguate the concept of the detailed plan for a clinical study (the scope of BRIDG at that time) from other kinds of protocols such as are common in life sciences. In BRIDG, the notion of a study protocol is very specific in purpose and includes (but is not limited to) the design, statistical considerations, activities to test a particular hypothesis or answer a particular question that is the basis of the study, characteristics, specifications, objective(s), background, pre-study/study/post-study portions of the plan (including the design, methodology, statistical considerations, organization).  For a more complete discussion of the notion of the study protocol see the classes StudyProtocol, StudyProtocolVersion, StudyProtocolDocument, StudyProtocolDocumentVersion, StudyConduct and all their associations.  <br/><br/>With the addition of life sciences to the scope of the BRIDG model, there came along (with that scope) the need to identify the kind of protocol that represents a more simple or atomic concept, that of “a composite activity that serves as a rule that guides how activities should be performed.”  This concept, represented by the ProcessProtocol class, has a more limited size than the concept of a study protocol does and represents a standardized approach to doing tasks or activities that are not as big as the plan for a whole study. <br/><br/>With the further addition of imaging concepts to the BRIDG model, there came the need to add further specific types of process protocols.  So the same term, ProcessProtocol has been leveraged with a prefix to indicate the scope of this subclass - ImagingProcessProtocol.<br/><br/>The BRIDG team acknowledges that overloaded terms are problematic. The team recognizes that many different users within the BRIDG community will have differing opinions on what the meaning of a term is, which term is the best to use for each concept, and how to define them most effectively. Given that the real “meat” of a concept is in the definition, the BRIDG team aims to choose the most unambiguous term to use as the class name, to make the class definition as explicit and clear as possible, to provide sufficient examples and other names to illustrate the range of possible instances that could be represented by the class.  So the BRIDG model is maintaining the distinction between a ProcessProtocol and a StudyProtocol because there is a distinction in the domain that we're trying to disambiguate - the concepts, attributes and relationships that describe an SOP-like, atomic, reusable ProcessProtocol are very different than those of a full-blown clinical trial StudyProtocol.  Linking the classes because they both contain the same overloaded word would create artificial complexity in the model and not serve the ultimate purpose of interoperability across systems that need to exchange biomedical research data.<br/>