public interface Participation extends InfrastructureRoot
Act and a Role with an
Entity playing that Role. Each Entity
(in a Role) involved in an Act in a certain way is
linked to the act by one Participation-instance. The kind of
involvement in the Act is specified by the
Participation.typeCode.
Examples: 1) Performers of acts (surgeons, observers, practitioners).
2) Subjects of acts, patient, devices
3) Locations
4) Author, co-signer, witness, informant
5) Addressee, information recipient
Rationale: Participations represent performance while roles represent
competence. Participations specify the actual performance of an
Entity in a certain Act, and thus a
Participation is scoped by its specific Act.
Conversely, roles specify the competence of an Entity (i.e., how
it may principally participate in what kinds of acts) irrespective of any
individual Act.
For example, the professional credentials of a person (Role) may
be quite different from what a person actually does (Participation). A common
example is interns and residents performing anesthesia or surgeries under
(more or less) supervision of attending specialists.
An Act can have multiple participations of the same type, which
indicates collaborative activities or group involvement. The notion of
multiple performing participations partially overlaps with sub-activities
(Act components). Whenever multiple actors are involved in an
act, each actor performs a different task (with the extremely rare exception
of such symmetrical activities as two people pulling a rope from either end).
Thus, the presence of multiple actors could be equally well represented as an
act consisting of sub-acts where each act would have only one performing
actor
For example, a record of a surgical service may include the actors of type: (a) consenter, (b) primary surgeon, and (c) anesthetist. These three actors really perform different tasks, which can be represented as three related acts: (a) the consent, (b) the surgery proper, and (c) the anesthesia act in parallel to the surgery. If we used the sub-acts, the consenter, surgeon and anesthetist could simply be of actor type "performer." Thus the more sub-acts we use, the fewer different actor types we need to distinguish; conversely, the fewer sub-acts we use, the more distinct actor types we need.
As a rule of thumb, sub-tasks should be considered instead of multiple actors when each sub-task requires special scheduling, or billing, or if overall responsibilities for the sub-tasks are different. In most cases, however, human resources are scheduled by teams (instead of individuals), billing tends to lump many sub-tasks together into one position, and overall responsibility often rests with one attending physician, chief nurse, or head of department. This model allows both the multi-actor and the multi-act approach to represent the business reality, with a slight bias towards "lumping" minor sub-activities into the overall act.
| Modifier and Type | Method and Description |
|---|---|
Act |
getAct()
Gets the
Act containing this Participation. |
Act |
getAct(ActFetch actFetch)
Gets the
Act that matches the criteria. |
CE |
getAwarenessCode()
A code specifying the extent to which the
Entity playing the
participating Role (usually as a target
Participation) is aware of the associated Act. |
CS |
getContextControlCode()
A code that specifies how this Participation contributes to the context
of the current
Act, and whether it may be propagated to
descendent acts whose association allows such propagation (see
ActRelationship.contextConductionInd). |
CD |
getFunctionCode()
An optional code specifying additional detail about the function that the
Participation has in the Act, if such detail is
not implied by the Participation.typeCode. |
CE |
getModeCode()
A code specifying the modality by which the
Entity playing
the Role is participating in the Act. |
BL |
getNegationInd()
If true, indicates that the specified participation did not, is not or
should not occur (depending on mood).
|
ED |
getNoteText()
A textual or multimedia depiction of commentary related to the
participation.
|
BL |
getPerformInd()
Indicates that the resource for this
Participation must be
reserved before use. |
Role |
getRole()
Gets the
Role participating in the Act. |
Role |
getRole(RoleFetch roleFetch)
Gets the
Role that matches the criteria. |
INT |
getSequenceNumber()
An integer specifying the relative order of the
Participation in relation to other participations of the
same Act. |
CE |
getSignatureCode()
A code specifying whether and how the participant has attested his
participation through a signature and or whether such a signature is
needed.
|
ED |
getSignatureText()
A textual or multimedia depiction of the signature by which the
participant endorses his or her participation in the
Act as
specified in the Participation.typeCode and that he or she
agrees to assume the associated accountability. |
CE |
getSubstitutionConditionCode()
Indicates the conditions under which a participating item may be
substituted with a different one.
|
IVL<TS> |
getTime()
An interval of time specifying the time during which the participant is
involved in the act through this
Participation. |
CS |
getTypeCode()
A code specifying the kind of Participation or involvement the
Entity playing the Role associated with the
Participation has with regard to the associated
Act. |
void |
setAwarenessCode(CE awarenessCode) |
void |
setContextControlCode(CS contextControlCode) |
void |
setFunctionCode(CD functionCode) |
void |
setModeCode(CE moodCode) |
void |
setNegationInd(BL negationNumber) |
void |
setNoteText(ED noteText) |
void |
setPerformInd(BL performanceInd) |
void |
setSequenceNumber(INT sequenceNumber) |
void |
setSignatureCode(CE signatureCode) |
void |
setSignatureText(ED signatureText) |
void |
setSubstitutionConditionCode(CE substitutionConditionCode) |
void |
setTime(IVL<TS> time) |
getControlAct, getToken, setTokenCS getTypeCode()
Entity playing the Role associated with the
Participation has with regard to the associated
Act.
Constraints: The Participant.typeCode contains only
categories that have crisp semantic relevance in the scope of HL7. It is
a coded attribute without exceptions and no alternative coding systems
allowed.
CD getFunctionCode()
Participation has in the Act, if such detail is
not implied by the Participation.typeCode.
Examples: First surgeon, second surgeon (or first assistant surgeon, the one facing the primary surgeon), second assistant (often standing next to the primary surgeon), potentially a third assistant, scrub nurse, circulating nurse, nurse assistant, anesthetist, attending anesthetist, anesthesia nurse, technician who positions the patient, postoperative watch nurse, assistants, midwives, students, etc.
Constraints: This code, if specified at all, must not be in conflict with
the Participation.typeCode. Automated systems should not
functionally depend on this code.
No HL7 standard specification may be written to technically depend on the
functionCode. If that is deemed necessary, such concepts
should be defined in the Participation.typeCode instead.
Discussion: This code can accommodate the huge variety and nuances of functions that participants may perform in the act. The number and kinds of functions applicable depends on the special kind of act. E.g., each operation and method may require a different number of assistant surgeons or nurses.
Since participation functions refer to what people do in an
Act, these are really sub-activities that may all occur in
parallel. If any more detail needs to be said about these activities
other than just who does them, one should consider using component acts
instead.
Act,
Participationvoid setFunctionCode(CD functionCode) throws HDRRimException
HDRRimExceptionCS getContextControlCode()
Act, and whether it may be propagated to
descendent acts whose association allows such propagation (see
ActRelationship.contextConductionInd).
Discussion: Refer to ActRelationship.contextControlCode for
rationale, discussion and examples.
void setContextControlCode(CS contextControlCode) throws HDRRimException
HDRRimExceptionINT getSequenceNumber()
Participation in relation to other participations of the
same Act.
Rationale: The sequencing might be undertaken for functional reasons or to establish a priority between participations. One example is the sequencing of covered party participations to establish a coordination of benefits sequence in insurance claims.
void setSequenceNumber(INT sequenceNumber) throws HDRRimException
HDRRimExceptionBL getNegationInd()
Rationale: This has two primary uses: (1) To indicate that a particular
Role did not/should not participate in an Act.
(2) To remove a participant from the context being propagated between
acts.
Discussion: A participation with a negationInd set to true is stronger than one with a negationInd of false. In other words, if there is a conflict, the negated participation takes precedence.
Examples: Dr. Smith did not participate; Patient Jones did not sign the consent.
void setNegationInd(BL negationNumber) throws HDRRimException
HDRRimExceptionED getNoteText()
void setNoteText(ED noteText) throws HDRRimException
HDRRimExceptionIVL<TS> getTime()
Participation.
Rationale: Participation time is needed when the participant's
involvement in the act spans only part of the Act's time.
Participation time is also used to indicate the time at which certain
very common sub-activities happen that are not worth mentioning in full
acts.
Examples: 1) The time data was entered into the originating system is the
Participation.time of the "data entry" participation.
2) The end of the participation time of an author is the time associated with the signature.
3) The Participation.time of a co-signing participation is
also the time of that co-signature.
void setTime(IVL<TS> time) throws HDRRimException
HDRRimExceptionCE getModeCode()
Entity playing
the Role is participating in the Act.
Examples: Physically present, over the telephone, written communication.
Rationale: Particularly for author (originator) participants this is used to specify whether the information represented by the act was initially provided verbally, (hand-)written, or electronically.
void setModeCode(CE moodCode) throws HDRRimException
HDRRimExceptionCE getAwarenessCode()
Entity playing the
participating Role (usually as a target
Participation) is aware of the associated Act.
Examples: For diagnostic observations, is the patient, family member or other participant aware of the patient's terminal illness?
Discussion: If the awareness, denial, unconsciousness, etc. is the
subject of medical considerations (example, part of the problem list),
one should use explicit observations in these matters as well, and should
not solely rely on this simple attribute in the
Participation.
void setAwarenessCode(CE awarenessCode) throws HDRRimException
HDRRimExceptionCE getSignatureCode()
Examples: A surgical Procedure act object (representing a
procedure report) requires a signature of the performing and responsible
surgeon, and possibly other participants. (See also:
Participation.signatureText.)
void setSignatureCode(CE signatureCode) throws HDRRimException
HDRRimExceptionED getSignatureText()
Act as
specified in the Participation.typeCode and that he or she
agrees to assume the associated accountability.
Examples: 1) An "author" participant assumes accountability for the truth
of the Act statement to the best of his knowledge.
2) An information recipient only attests to the fact that he or she has received the information.
Discussion: The signature can be represented in many different ways either inline or by reference according to the ED data type. Typical cases are:
1) Paper-based signatures: the ED data type may refer to some document or file that can be retrieved through an electronic interface to a hardcopy archive.
2) Electronic signature: this attribute can represent virtually any electronic signature scheme.
3) Digital signature: in particular, this attribute can represent digital signatures, for example, by reference to a signature data block that is constructed in accordance to a digital signature standard, such as XML-DSIG, PKCS#7, PGP, etc.
void setSignatureText(ED signatureText) throws HDRRimException
HDRRimExceptionBL getPerformInd()
Participation must be
reserved before use. (i.e, it is controlled by a schedule).
Rationale: This attribute serves a very specific need in the context of resource scheduling. It is not needed in the majority of participation expressions. In most circumstances, it applies to the participation of a particular location or piece of equipment whose use is controlled by a scheduler.
void setPerformInd(BL performanceInd) throws HDRRimException
HDRRimExceptionCE getSubstitutionConditionCode()
void setSubstitutionConditionCode(CE substitutionConditionCode) throws HDRRimException
HDRRimExceptionRole getRole() throws HDRRimException
Role participating in the Act.
Roles on participations are immutable, the Role is specified
while constructing the participation. Methods for constructing the
Participation are available on Act and
Act subclasses
Role taking part in this
Participation.HDRRimExceptionRole getRole(RoleFetch roleFetch) throws HDRRimException
Role that matches the criteria.roleFetch - RoleFetch object containing the search
criteriaIterator containing matching roles according to the
specified fetch map.HDRRimExceptionAct getAct() throws HDRRimException
Act containing this Participation.
The Participation can be said to be owned by the
Act.
Act taking part in this
Participation.HDRRimExceptionAct getAct(ActFetch actFetch) throws HDRRimException
Act that matches the criteria.actFetch - ActFetch object containing the search
criteriaIterator containing matching acts according to the
specified fetch map.HDRRimExceptionHDR Glossary HDR Concept Lists HDR Exceptions HDR Programmer's Guide HDR Implementation Guide HDR Profile Options
Copyright © 2016, 2018, Oracle. All rights reserved