This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "De-blue MessageCommunicationsControl"

From HL7Wiki
Jump to navigation Jump to search
 
(10 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
{{INM Workitem}}
 
{{INM Workitem}}
{{MnM Open Hot Topic}}
+
{{INM Motion|Committee feels we should move forward and de-blue the models as a strategy. Has a number of advantages, Mark T/Rene, 6-0-0, January 2007 WGM}}
 +
 
 +
''See the [[Talk:{{PAGENAME}}|discussion page]] for discussions.''
 +
 
 
[[Image:RIM MessageCommunicationsControl.gif|250px|right|thumb|MessageCommunicationsControl subject area]]  
 
[[Image:RIM MessageCommunicationsControl.gif|250px|right|thumb|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 [[Interaction]]s (e.g. Messages, Batches) to be exchanged.  See [[HL7 Messaging Architecture]].
 
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 [[Interaction]]s (e.g. Messages, Batches) to be exchanged.  See [[HL7 Messaging Architecture]].
  
==Discussion==
+
==Details==
  
===Question: Why are the blue classes blue?===  
+
===Why haven't the MessageCommunicationsControl classes been modelled using the 4 base classes?===  
  
 
As for the original reason to create these classes when the RIM was initially developed:  
 
As for the original reason to create these classes when the RIM was initially developed:  
Line 13: Line 16:
 
*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.
 
*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.
  
 +
===Why are the classes "blue" (as opposed to another color)===
 
As for the "blueness" of the classes:
 
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 [http://en.wikipedia.org/wiki/UML_colors 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.'
 
*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 [http://en.wikipedia.org/wiki/UML_colors 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==
 
==Future Options==
[[Image:Wrappers_blue.jpg|300px|right|thumb|Transmission wrappers]]
+
Given various discussions within [[INM]] as well as with the [[SOA SIG]] some radical changes have to be made to the [[Transmission Wrapper]]s. 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 been raised whether or not the blue classes should be remoddeled as base RIM classes. This adds some abstraction ([[Structural Attributes]]) which will show at the XML level.  
 
 
Given various discussions within [[INM]] as well as with the [[SOA SIG]] some radical changes have to be made to the [[Transmission Wrapper]]s. [[Harmonization: Transmission Inheritance|Inheretance]] has recently been approved for the blue classes. There is a discussion related to [[Harmonization: turn ParameterItem.semanticsText into a mandatory attribute|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.
 
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:
+
MnM sees no functional objection to the wrappers being remodelled in terms of the base classes.
[[Image:Wrappers_red2.jpg|300px|right|thumb|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.
 

Latest revision as of 16:49, 30 January 2007

See the discussion page for discussions.

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.

Details

Why haven't the MessageCommunicationsControl classes been modelled using the 4 base classes?

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.

Why are the classes "blue" (as opposed to another color)

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

Given various discussions within INM as well as with the SOA SIG some radical changes have to be made to the Transmission Wrappers. 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 been raised whether or not the blue classes should be remoddeled as base RIM classes. 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.

MnM sees no functional objection to the wrappers being remodelled in terms of the base classes.