Participation

Closed: At May 2009. There has been no action on this in 30 months, and there are now RIM ballots and Harmonization in which to address this.

For Participation of persons in HL7 activities, see Marketing Committee.

A Participation is one of the RIM base classes.

NOTE: Open issue is a) add id and statusCode to Participation and deprecate the Managed Participation class in the RIM, b) provide clear and unambiguous guidelines for the use of sub-acts versus perticipation.statuscode (see Gunthers comments below).

See Trigger Event for a discussion of the use of trigger events based on participations, and for interactions related to a "Request for a change in participation".

Managed Participations

A Managed Participation is a specialization of the base Partcipation class, which adds two optional attributes: id and statusCode.

If there is a participation type for which one needs to use the status code and time range, these attributes can be used. The id attribute was added as a standard method of identifying two similar participations in order to distinguish the two when updating (Norman: as I recall Update Mode was in limbo at the time).

History & Discussion

(Norman) At the RIM Harmonization meeting where the attributes id and status code were added, a few people strongly objected because they felt no use for these (since no committees other than Patient Administration had identified a need for them, it was thought they were unnecessary) and wanted them to be a separate class to avoid confusion. I don't recall if the participation.time attribute was added at the same meeting or not, but the time and statusCode attribute are frequently used in conjunction.

(Gregg) I can only say that when we (PA) proposed state machines for Role, Entity, and Participation there was strong feeling that Participation should be stateless. The compromise was to create the new class.

(Norman) It turns out adding those two attributes to a separate class and using the name Managed Participation probably caused more confusion than just adding them to the Participation class would have. I have wasted a considerable amount of time dealing with the rampant confusion that has caused to people who have examined the two classes carefully.

Plus other groups have indicated the value of effectivetime and statuscode.

I don't think it matters one way or the other with respect to any derived messages if the attributes in ManagedParticipation were moved to the Participation class.

(Rene) Having two different classes only makes sense if one can state that particular participations can never have a state. Barring such a use case we could simply create a harmonization proposal to move these two attributes up the RIM class hierarchy and deprecate the Managed Participation class. This has no backwards compatibility issues associated with it.

I fail to see why we have two different RIM classes if all participations can always be modeled as ManagedParticipations.

(Gunther) The big question is what we are talking about when we say "status". I think, we really should have two separate distinct statuses here, of which Act has 2, and Entity has only one.

1. One would be a "record status", i.e., the status of the instance of data about the Entity, Act or other real world object.
   • Things like: obsolete and nullified are record status.
2. The second is the status of an Act in the real world.
   • Active, completed, aborted, suspended, etc. are real act status.

The Entity is, as you say, stateless (or should be) so it would only have a record status. Act has inherent state, so it has record status and real status. Now Participation is a chamaeleon: it is on the one hand just a piece of glue, and on the other hand can represent sub-activities.

I never liked status on Participations as it seems to duplicate what should be done with sub-acts. If it's just a record status, then it would be no big deal, as all RIM classes could have a record status. But if it is a real world sub-activity status, then it's a problem. That's why it was pushed out into a specialized class so that people wouldn't just use it without much thinking.

Notes

• How do I define a participation to be a "managed participation" ?

Any participation can be defined as a managed participation. In the RMIM Designer (Visio) look for the check box on the right side of the 'Controlling Attribute(s)' section of the participation editor. Click that and you get the two additional attributes, id and statusCode.