: Public <<Comment_Requested>> Class
DEFINITION:<br /></p><p>A composite activity that serves as a rule that guides how activities should be performed.<br /></p><p><br /></p><p>EXAMPLE(S): Specimen Collection Protocol; Specimen Processing Protocol; Image Acquisition Protocol<br /></p><p><br /></p><p>OTHER NAME(S):<br /></p><p><br /></p><p>QUESTION(S):<br /></p><p>1. Should BRIDG consider renaming this class to ProcessProtocol to distinguish it from other kinds of protocols? (See NOTE(S) below.)<br /></p><p><br /></p><p>NOTE(S):<br /></p><p>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 /></p><p><br /></p><p>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 Protocol 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 /></p><p><br /></p><p>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. The SCC would like to solicit feedback from the community on representational choices that have been made as well as the class name and other aspects of the model.<br /></p>
- Attributes
- Associations From
- Tagged Values
- Other Links
Attribute |
Public ST title
|
Details:
Alias: |
|
Initial: |
|
Stereotype: |
|
Ordered: |
|
Range: |
Range:0 to 1 |
Transient: |
False |
Derived: |
False |
IsID: |
False |
Notes:
|
DEFINITION:#lt;br /#gt;#lt;/p#gt;#lt;p#gt;The textual designation by which the protocol is referenced.#lt;br /#gt;#lt;/p#gt;#lt;p#gt;#lt;br /#gt;#lt;/p#gt;#lt;p#gt;EXAMPLE(S):#lt;br /#gt;#lt;/p#gt;#lt;p#gt;#lt;br /#gt;#lt;/p#gt;#lt;p#gt;OTHER NAME(S):#lt;br /#gt;#lt;/p#gt;#lt;p#gt;#lt;br /#gt;#lt;/p#gt;#lt;p#gt;NOTE(S):#lt;br /#gt;#lt;/p#gt;
|
|
Element |
Source Role |
Target Role |
PointOfContact
Class
|
Name: supportingPointOfContact
|
Name: supportedProtocol
|
 Details:
DESCRIPTION:<br /></p><p>Each PointOfContact might support one or more Protocol. Each Protocol might be supported by one or more PointOfContact.<br /></p><p><br /></p><p>DEFINITION:<br /></p><p><br /></p><p>EXAMPLE(S):<br /></p><p><br /></p><p>OTHER NAME(S):<br /></p><p><br /></p><p>NOTE(S):<br /></p>
|
Organization
Class
|
Name: followingOrganization
|
Name: followedProtocol
|
 Details:
DESCRIPTION:<br /></p><p>Each Organization might follow one or more Protocol. Each Protocol might be followed by one or more Organization.<br /></p><p><br /></p><p>DEFINITION:<br /></p><p><br /></p><p>EXAMPLE(S):<br /></p><p>An imaging center may follow a given image acquisition protocol<br /></p><p><br /></p><p>OTHER NAME(S):<br /></p><p><br /></p><p>NOTE(S):<br /></p>
|
DocumentVersion
Class
|
Name: containingDocumentVersion
|
Name: containedProtocol
|
 Details:
DESCRIPTION:<br /></p><p>Each DocumentVersion might contain one Protocol. Each Protocol might be the contents of one DocumentVersion.<br /></p><p><br /></p><p>DEFINITION:<br /></p><p><br /></p><p>EXAMPLE(S):<br /></p><p><br /></p><p>OTHER NAME(S):<br /></p><p><br /></p><p>NOTE(S):<br /></p>
|
Tag |
Value |
Map:LSDAM |
Protocol |
 Details:
|
Map:LSDAMv2.2.3Plus |
Protocol |
 Details:
|
Object |
Type |
Connection |
Direction |
Notes |
DefinedActivity |
Class |
Generalization |
To |
DESCRIPTION:
Each Protocol always specializes one DefinedActivity. Each DefinedActivity might be specialized by one Protocol.
DEFINITION:
EXAMPLE(S):
OTHER NAME(S):
NOTE(S): |
«placeholder» ImageAcquisitionProtocol |
Class |
Generalization |
From |
DESCRIPTION:
Each ImageAcquisitionProtocol always specializes one Protocol. Each Protocol might be specialized by one ImageAcquisitionProtocol.
DEFINITION:
EXAMPLE(S):
OTHER NAME(S):
NOTE(S): |
SpecimenProcessingProtocol |
Class |
Generalization |
From |
DESCRIPTION:
Each SpecimenProcessingProtocol always specializes one Protocol. Each Protocol might be specialized by one SpecimenProcessingProtocol.
DEFINITION:
EXAMPLE(S):
OTHER NAME(S):
NOTE(S): |
SpecimenCollectionProtocol |
Class |
Generalization |
From |
DESCRIPTION:
Each SpecimenCollectionProtocol always specializes one Protocol. Each Protocol might be specialized by one SpecimenCollectionProtocol.
DEFINITION:
EXAMPLE(S):
OTHER NAME(S):
NOTE(S): |