This wiki has undergone a migration to Confluence found Here
Difference between revisions of "R-MIM"
Jump to navigation
Jump to search
Rene spronk (talk | contribs) |
Joelfinkle (talk | contribs) (→FAQ) |
||
| (2 intermediate revisions by 2 users not shown) | |||
| 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. | ||
Latest revision as of 19:04, 5 May 2008
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.
