Reconciling Issues re Performer & Assessor
06/14/2016
What’s raising this issue
• For some time now there has been issues with the
different use and purpose of the Performer and Assessor
classes
• There are 3 open issues in Jira related to this topic
• The current effort of mapping DICOM to BRIDG is
bringing a new use case that requires a change to the
BRIDG model
• It’s a use case we knew was out there but it had not
been brought to harmonization before
• So we propose addressing all the Performer/Assessor
related issues at once to make sure we are consistent in
our approach
Current Associations on Performer and Assessor in BRIDG
class Performer v s Assessor
Name:
Package:
Version:
Author:
Performer vs Assessor
Performer vs Assessor
NEW - Additional Focused Views
1.0
wverhoef
Common SubDomain::Person
is a function performed by
{function as}
1
0..*
View Description: This diagram show a comparison between the associations on Performer vs the associations
on Assessor for the purposes of discussing a better, more clear representation of the semantics.
Common Sub-Domain::
HealthcareProv ider
be a function performed by
{function as}
0..1
Study Conduct Sub-Domain::
Assessor
0..*
+
Common Sub-Domain::
ResearchStaff
is a function performed by
{function as}
1
Common SubDomain::
BiologicEntity
0..*
evaluatorAlias: ST [0..1]
be a function performed by
{function as}
0..1
0..*
is a function performed by
{function as}
1
0..*
Common Sub-Domain::
AssociatedBiologicEntity
be a function performed by
{function as}
0..1
0..*
is scoped by
{scope}
1
0..1
0..*
be a function performed by
{function as}
0..1
0..*
Common SubDomain::Subj ect
be a function performed by
be a function performed by
{function as}
Study Conduct
Sub-Domain::
StudySite
be a function performed by
Common SubDomain::
Organization
be a function
performed by
0..* {function as}
0..1
{function as}
{function as}
0..1
be a function
performed by
0..1
{function as}
0..*
is a function performed by
{function as}
1
0..1
0..1
0..1
Study Conduct SubDomain::Laboratory
Common Sub-Domain::
Ov ersightAuthority
be performed at
{perform}
0..*
0..*
{function as}
Product
performs
3
0..1
{function as}
0..*
be a function performed by
{function as}
0..*
0..*
1..*
Study Conduct Sub-Domain::
PerformedAdministrativ eActiv ity
be a function performed by
be performed by
{perform}
{be performed by}
Common Sub-Domain::Activity
Study Conduct SubDomain::
PerformingLaboratory
0..1
Common Sub-Domain::
Ov ersightCommittee
Common Sub0..1
Domain::
Dev ice
0..1
0..*
{function as}
0..*
be a function
performed by
{function as}
0..1
0..*
identifier: II [0..1]
typeCode: CD [0..1]
postalAddress: AD [0..1]
telecomAddress: BAG<TEL> [0..*]
effectiveDateRange: IVL<TS.DATETIME> [0..1]
0..*
be a function
performed by
1
is a function
performed by
Common Sub-Domain::Performer
+
+
+
+
+
0..*
0..*
be a function performed by
0..1
{function as}
0..1
Study Conduct Sub-Domain::PerformedActiv ity
0..1
be reported by
{report}
0..*
Study Conduct Sub-Domain::PerformedObserv ation
Summary of Associations
• Performer – associations go to entities directly, no roles; used
for everything except Observations for which it is excluded by
a constraint:
– Person
– Organization
– Device
Role of
person/org/device is
often not provided
• Assessor – associations to assorted role classes plus one
entity; used only on Observations:
–
–
–
–
–
–
–
HealthcareProvider
ResearchStaff
AssociatedBiologicEntity
Subject
Laboratory
OversightCommittee
Device
Knowing roles is
essential for
determining relative
value of observations
Highlighted Issues
class Performer v s Assessor
Name:
Package:
Version:
Author:
Performer vs Assessor
Performer vs Assessor
NEW - Additional Focused Views
1.0
wverhoef
Common SubDomain::Person
Need to
cover both
attribute
sets
is a function performed by
{function as}
1
0..*
View Description: This diagram show a comparison between the associations on Performer vs the associations
on Assessor for the purposes of discussing a better, more clear representation of the semantics.
Common Sub-Domain::
HealthcareProv ider
be a function performed by
{function as}
0..1
Study Conduct Sub-Domain::
Assessor
0..*
+
Common Sub-Domain::
ResearchStaff
is a function performed by
{function as}
1
Common SubDomain::
BiologicEntity
0..*
evaluatorAlias: ST [0..1]
be a function performed by
{function as}
0..1
0..*
is a function performed by
{function as}
1
0..*
Common Sub-Domain::
AssociatedBiologicEntity
be a function performed by
{function as}
0..1
0..*
is scoped by
Wording
implies could
be subject or
performer
Study Conduct
Sub-Domain::
StudySite
{scope}
1
0..1
0..*
be a function performed by
{function as}
0..1
0..*
Common SubDomain::Subj ect
be a function performed by
be a function performed by
{function as}
be a function performed by
Common SubDomain::
Organization
be a function
performed by
0..* {function as}
0..1
{function as}
{function as}
0..1
be a function
performed by
0..1
{function as}
0..*
is a function performed by
{function as}
1
0..1
0..1
0..1
Study Conduct SubDomain::Laboratory
Common Sub-Domain::
Ov ersightAuthority
be performed at
{perform}
0..*
0..*
{function as}
Product
performs
be a function performed by
{function as}
0..1
0..*
be a function performed by
{function as}
0..*
be performed by
{perform}
{be performed by}
0..*
1..*
Common Sub-Domain::Activity
redundant
Study Conduct SubDomain::
PerformingLaboratory
0..1
Common Sub-Domain::
Ov ersightCommittee
Common Sub0..1
Domain::
Dev ice
0..1
0..*
{function as}
0..*
be a function
performed by
{function as}
0..1
0..*
identifier: II [0..1]
typeCode: CD [0..1]
postalAddress: AD [0..1]
telecomAddress: BAG<TEL> [0..*]
effectiveDateRange: IVL<TS.DATETIME> [0..1]
0..*
be a function
performed by
1
is a function
performed by
Common Sub-Domain::Performer
+
+
+
+
+
0..*
0..*
be a function performed by
0..1
{function as}
0..1
Study Conduct Sub-Domain::PerformedActiv ity
doesn’t make sense
0..*
Study Conduct Sub-Domain::PerformedObserv ation
Study Conduct Sub-Domain::
PerformedAdministrativ eActiv ity
5
0..1
be reported by
{report}
inconsistent
Related Jira Tracker Issues
• Redundancy between PerformingLaboratory and Assessor
– Need to have only one path between PerfObs and the laboratory
that performs it
• Can an observation have both a person and a device as
assessor?
– Many times it’s important to capture both a device and the
person who operates the device, e.g. imaging, sometimes even
more than one device and more than one person
– The term “assessor” is not the best fit for such observations –
need performer and assessor
• Performer association between
PerformedAdministrativeActivity and StudySite
– Need to resolve redundancy and ambiguity – StudySite as
Subject and as Performer
• (See issue details in reference section at end of slides if
interested)
Principles on which the change proposals are based
• Redundant relationships add confusion and cause
inconsistency in models and implementations (code and
databases)
• Cardinality on associations must support reality (more
than one performer/assessor is often required, same
Performer on different activities is a different
performance, thus a different Performer)
• Specificity supported in Assessor associations can be
additional options on Performer
– Any given use case needs to determine whether rolebased specificity is required
Proposed Changes
•
•
•
Or should we leverage
Performer.typeCode to
– Add association from Subject to StudySite
represent whether it’s
– Add association from Performer to StudySite
– Drop association from PerformedAdministrativeActivity to StudySite a Performing or
Collecting lab, drop
Laboratory set:
the Perf/CollLab
– Add association from Performer to PerformingLaboratory
classes and have all
– Add association from Performer to CollectingLaboratory
associations go to
– Drop association from Assessor to Laboratory
Laboratory?
Assessor merges into Performer set:
StudySite set:
–
–
–
–
–
–
–
–
Move association from Assessor to HealthcareProvider to start from Performer
Move association from Assessor to ResearchStaff to start from Performer
Move association from Assessor to AssociatedBiologicEntity to start from Performer
Move association from Assessor to Subject to start from Performer
Move association from Assessor to OversightCommittee to start from Performer
Move evaluatorAlias attribute from Assessor to Performer
(association from Performer to Device is already there)
Change cardinality on the Activity end of the association from Performer to Activity to
be 1, not 1..*)
– Update definition of Performer – see next slide
– Drop Assessor class and constraint on PerformedObservation excluding use of
Performer for PerfObs
•
Move all tags as appropriate
Reconciling Performer & Assessor Definitions
Performer
DEFINITION:
A person,
organization or
device that
participates in an
activity.
EXAMPLE(S):
surgeon, performing
laboratory,
monitoring device
OTHER NAME(S):
NOTE(S):
Assessor
DEFINITION:
The person, organization, or
device making an observation.
EXAMPLE(S):
healthcare provider,
adjudication committee, family
member, radiologist, vendor
(may provide a uniform
assessment for all sites
participating in a study), heart
rate monitor, pace maker.
OTHER NAME(S):
NOTE(S):
Performer (Proposed Updates)
DEFINITION:
The person, organization, or device that
participates in an activity.
EXAMPLE(S):
surgeon, performing laboratory, monitoring
device, healthcare provider, adjudication
committee, family member, radiologist, vendor
(may provide a uniform assessment for all sites
participating in a study), heart rate monitor,
pace maker.
OTHER NAME(S):
Assessor
NOTE(S):
A Performer may be simply a person,
organization or device or it may be a person,
organization or device in a particular role that is
important for understanding or interpreting the
significance of the activity or its results, such as
with observations.
For Reference
BRIDG UML Jira Issues
Jira Tracker Issue – BRIDGUML-31
• Redundancy between PerformingLaboratory and Assessor
– PerformedObservation and Laboratory can be "connected" by way
of either PerformingLaboratory or Assessor. I don't understand
whether there's a real difference between the use of these two
classes. Neither has any attributes. There is some difference in the
cardinality of the associations:
• The cardinality at the PerformedObservation end of the link to Assessor
is 0...* while the cardinality at the PerformedObservation end of the link
to PerformingLaboratory is 1...*.
• The cardinality at the Laboratory end of the link to Assesor is 0...1 while
the cardinality at the Laboratory end of the link to PerformingLaboratory
is 1.
• This difference may reflect just reflect the fact that
PerformingLaboratory is used only to link PerformedObservation while
Assessor is used to link one of six different classes to
PerformedObservation.
• If there is a real difference between the two classes I would like advice
on when to use which one. Otherwise I think that PerformingLaboratory
should probably be dropped.
Jira Tracker Issue – BRIDGUML-213
• Can an observation have both a person and a device
as assessor?
– There are situations where we would want to know both the person or
organizaition making an observation and the device used in making an
observation when there is skill involved in using the process of using the
equipment to make an observation. For example electrocardiography uses a
device but there is quite a bit of skill in how the device is used. However each
PerformedObservation is reported by one Assessor. Is there a different
relationship that should be used for the device or for the person using the
device?
– This question originally arose in the context of spirometry where the
spirometer device is clearly important but the coaching of the subject in
performing the breathing maneuvers measured by the device are also
important.
Jira Tracker Issue – BRIDGUML-26
• Performer association between
PerformedAdministrativeActivity and StudySite
– While researching a CTR-proposed new association between
Subject and a HealthcareFacility (HCF) that may play the role of
Subject in an administrative activity such as audit it was discovered
that there is a "performer" association between
PerformedAdministrativeActivity and StudySite. This association
has been in the model since BRIDG 1.0 was released so there is
likely no record of where the requirement came from. Additionally
the association label has remained the same throughout the release
history of BRIDG so this was definitely not a case of changed
semantics. It does seem somewhat redundant with the existing
Performer class though.
– Should this association be reconciled with the Performer class
which can be played by a Person, Organization or Device? Options
to consider include, but are not limited to, the following: just drop the
association and say that the Organization playing the role of
Performer may additionally play the role of HCF or StudySite; add
an association to HCF (and possibly StudySite) from Performer to
accommodate the specific semantic; make no changes.