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) (→FAQ) |
Joelfinkle (talk | contribs) (→FAQ) |
||
| Line 7: | Line 7: | ||
**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. | **In short: There is no requirement that an "implementable R-MIM" (or: a message type) has to contain fixed moodCodes. | ||
| + | * This is a question about to be removed | ||
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.
- This is a question about to be removed
