This wiki has undergone a migration to Confluence found Here

Difference between revisions of "R-MIM"

From HL7Wiki
Jump to navigation Jump to search
Line 6: Line 6:
 
*Is it true that the ''moodCode'' attribute needs to have a fixed value in an R-MIM (as opposed to the D-MIM where it may be one of the values in a specified vocabulary)?
 
*Is it true that the ''moodCode'' attribute needs to have a fixed value in an R-MIM (as opposed to the D-MIM where it may be one of the values in a specified vocabulary)?
 
**No. Certainly as a general pattern, if you're creating a domain that deals with "pharmacy" or "lab" or "encounters" where different moods have meaning, then your D-MIM should support multiple moods (though it might do so by having multiple entry-points on mood-specific classes). And in some cases, a (high-level) R-MIM may still allow some ambiguity in mood, particularly for things like "<=INT" where you want to support both orders and proposals for example.
 
**No. Certainly as a general pattern, if you're creating a domain that deals with "pharmacy" or "lab" or "encounters" where different moods have meaning, then your D-MIM should support multiple moods (though it might do so by having multiple entry-points on mood-specific classes). And in some cases, a (high-level) R-MIM may still allow some ambiguity in mood, particularly for things like "<=INT" where you want to support both orders and proposals for example.
 +
**In short: There is no requirement that an "implementable R-MIM" (or: a message type) has to contain fixed moodCodes.

Revision as of 00:58, 7 January 2007

A Refined-Message Information Model (R-MIM) is a constraint on a D-MIM which has a single entry point and can therefore be serialized, and used in information systems. This type of model is defined in the MDF.

In due time these terms may/will be replaced by CIM.

FAQ

  • Is it true that the moodCode attribute needs to have a fixed value in an R-MIM (as opposed to the D-MIM where it may be one of the values in a specified vocabulary)?
    • No. Certainly as a general pattern, if you're creating a domain that deals with "pharmacy" or "lab" or "encounters" where different moods have meaning, then your D-MIM should support multiple moods (though it might do so by having multiple entry-points on mood-specific classes). And in some cases, a (high-level) R-MIM may still allow some ambiguity in mood, particularly for things like "<=INT" where you want to support both orders and proposals for example.
    • In short: There is no requirement that an "implementable R-MIM" (or: a message type) has to contain fixed moodCodes.