: Public Class
Created: 9/3/2013 4:18:45 PM
Modified: 8/26/2017 2:00:43 AM
DEFINITION:<br/>A standard operating procedure (SOP) that is a collection of activities and the rules that describe when each activity is performed to achieve a specific purpose or objective(s).<br/><br/>EXAMPLE(S):  Specimen Collection Protocol; Specimen Processing Protocol; Image Acquisition Protocol<br/><br/>OTHER NAME(S):<br/><br/>NOTE(S):<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/>The BRIDG SCC acknowledges that overloaded terms are problematic. The SCC 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 SCC 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/>
Public ST
Map:DICOM=Protocol Context Module - Protocol Name (0018,1030)
Map:DICOM=General Series Module - Protocol Name (0018,1030)
Notes: DEFINITION:<br/>The textual designation by which the protocol is referenced.<br/><br/>EXAMPLE(S):<br/><br/>OTHER NAME(S):<br/><br/>NOTE(S):<br/>
Element Source Role Target Role
Name: followingOrganization
Name: followedProtocol
DESCRIPTION:<br/>Each Organization might follow one or more ProcessProtocol.  Each ProcessProtocol might be followed by one or more Organization.<br/><br/>DEFINITION:<br/><br/>EXAMPLE(S):<br/>An imaging center may follow a given image acquisition protocol<br/><br/>OTHER NAME(S):<br/><br/>NOTE(S):<br/>
Name: supportingPointOfContact
Name: supportedProtocol
DESCRIPTION:<br/>Each PointOfContact might support one or more ProcessProtocol.  Each ProcessProtocol might be supported by one or more PointOfContact.<br/><br/>DEFINITION:<br/><br/>EXAMPLE(S):<br/><br/>OTHER NAME(S):<br/><br/>NOTE(S):<br/>
Name: containingDocumentVersion
Name: containedProtocol
DESCRIPTION:<br/>Each DocumentVersion might contain one ProcessProtocol. Each ProcessProtocol might be the contents of one DocumentVersion.<br/><br/>DEFINITION:<br/><br/>EXAMPLE(S):<br/><br/>OTHER NAME(S):<br/><br/>NOTE(S):<br/>
Tag Value
Map:LSDAMv2.2.3Plus Protocol
Object Type Connection Direction Notes
SpecimenProcessingProtocol Class Generalization From DESCRIPTION: Each SpecimenProcessingProtocol always specializes one ProcessProtocol. Each ProcessProtocol might be specialized by one SpecimenProcessingProtocol. DEFINITION: EXAMPLE(S): OTHER NAME(S): NOTE(S):
ImagingProcessProtocol Class Generalization From DESCRIPTION: Each ImagingProcessProtocol always specializes one ProcessProtocol. Each ProcessProtocol might be specialized by one ImagingProcessProtocol. DEFINITION: EXAMPLE(S): OTHER NAME(S): NOTE(S):
DefinedActivity Class Generalization To DESCRIPTION: Each ProcessProtocol always specializes one DefinedActivity. Each DefinedActivity might be specialized by one ProcessProtocol. DEFINITION: EXAMPLE(S): OTHER NAME(S): NOTE(S):
SpecimenCollectionProtocol Class Generalization From DESCRIPTION: Each SpecimenCollectionProtocol always specializes one ProcessProtocol. Each ProcessProtocol might be specialized by one SpecimenCollectionProtocol. DEFINITION: EXAMPLE(S): OTHER NAME(S): NOTE(S):