De-blue MessageCommunicationsControl

MessageCommunicationsControl subject area

The MessageCommunicationsControl subject area of the RIM (informally known as the blue classes or the bottom half of the RIM), supports transmission oriented functions which allow Interactions (e.g. Messages, Batches) to be exchanged. See HL7 Messaging Architecture.

Discussion

Question: Why are the blue classes blue?

As for the original reason to create these classes when the RIM was initially developed:

• It was not felt to be part of the 'shared, cross-domain semantics that the RIM was designed to represent.' Rather, it represented a 'resource' of messaging-appropriate semantics (remember, the RIM stared out as an internal document that was only imagined to be referenced by specification developments and never used as an information-model per se. But even in this view, the 'blue' classes were deemed to be on a different plane than the other classes and, at least in some sense, did seem vaguely conceptually similar to Coad's blue classes.). Various ITSs would utilize various aspects of the blue classes in implementation-specific ways in contrast to much of the RIM semantics per se, which would, for the most part, be utilized as modeled.
• At the Harmonization Meeting where this was decided, one person felt very strongly that the RIM Backbone was designed to apply to healthcare-specific portions of the RIM (it was designed with those portions in mind) and that the healthcare-specific portion was what HL7 had the most to offer to the world; several others tended to agree. There were several people who disagreed and felt the same modeling paradigm should apply throughout the entire model. Plus those portions in what is now called the MessageCommunicationsControl portion of the model were not modeled (at that time) in a similar fashion or with the same level of rigor and review. Plus there were no modeling personnel resources available at the time to enhance that portion of the model.

As for the "blueness" of the classes:

• It came from a permutation on Peter Coad's "Java Modeling in Color with UML by Peter Coad" (ISBN:0-13-011510-X) in which blue is for 'catalogue' or 'reference' classes. See Wikipedia on UML colors for a description. The other RIM colors are also derivatives of that coloring scheme. 'event' was red (hence Act and its derivative ActRelationship), Role was yellow, and Party (our Entity) was green. Coad didn't have the notion of Participation so we came up with tourquoise and reserved blue for the closest we had to 'catalogue or fixed resource.'

Future Options

Transmission wrappers

Given various discussions within INM as well as with the SOA SIG some radical changes have to be made to the Transmission Wrappers. Inheritance has recently been approved for the blue classes. There is a discussion related to the use of structural attributes in the parameterItem (blue) class. Increasingly the blue classes exhibit the same characteristics as the base RIM classes. Given the fact that things like Document and Application etc. already are RIM classes the question has to be raised whether or not the blue classes should be remoddeled as base RIM classes.

Use, but remove from RIM

Dan Russler (in an e-mail, paraphrasing) suggests not to include the blue classes in the RIM anymore (but to keep on using them)

Replace by RIM classes

Replacing the blue classes by RIM classes is an option. This adds some abstraction (Structural Attributes) which will show at the XML level.

There is a secundary motivation for doing this: it will allow for requirements analysis to be (re)done. The existing blue classes were mostly ported from v2 and are based on requirements that may not exist for v3. The fact that INM has already removed attributes from the blue classes because of a "lack of underlying use-case" is a symptom of the need to do a requirements analysis.

A mapping is feasable:

RIM based wrappers (mockup)

• Message is an act,there is a participation/role/entity for for CommunicationFunction
• Attachment is just message.txt
• There is an ActRelationship for Acknowledgement to another message or transmission
• Batch has an ActRelationship to batches or messages.
• Acknowledgement detail is another act relationship/act?
• QueryByParameter is the act of querying. ParameterList is some kind of collection Act.
• ParameterItem is a problem if one attempts to fully model it - it can be any of the 6 base classes or an attribute. Only real options are to either stick with blue for parameter, or to be creative and use a "creative" act (the act of "selecting a subset") which is essentially a key/value pair.

WGM Sept2006, 20060911

At the joint MnM/INM meeting the issue was discussed. Rene reviewed the contents of the Wiki page (as of 20060911), and showed the mockup model. Grahame: another reason for doing this is related to ITS problems, because blue classes are different, no structural attributes. Initial response awful, but looking at it there may be good reasons. Woody: a RIM question. Will it lead to greater clarity. Document is a precedent, unfortunately. Grahame: initially felt the same, spent time working on what it would look like. More expressive, if you understand RIM more naturally, not convinced that its particularly worse. Craig: if redone, through ballot process, let it go ahead, go to ballot. Lloyd: any specific questions that INM should answer? Woordy: Can all of the concepts be expressed? Would some UML transport standards not be more appropriate? Charlie: mutiple options there. Grahame: grey zone advanced/simple transport.

Lee C: There are R1 implemntations, this is a radical change.

Need a comlete "mapping".

Charlie: slight disquite, not a methodlogical objection.

2006911: While there were some concerns MnM sees no functional objection and request a proposal (to represent the existing structures based on analysis supported by requirements) to do a mapping to RIM backbone. Evaluation of this more proposal [outcome by MnM to see if there is no methodlogical misfit] (Charlie/Woody, 21-0-3)