Executive Summary

Notes on RMIM Reshaping – R. Worden

1. Overview of the RMIM Shaper Tool

The RMIM shaper reads in a V3 RMIM (from a MIF file) and then lets you carry out a sequence of steps to restrict and reshape the RMIM. These steps are intended to make the model simpler, easier for domain experts to understand, and easier to map onto healthcare IT systems. They should make XML message instances based on the reshaped model smaller and easier to read than instances of the full XML ITS. Generally, they should make the model look more like a domain analysis model. A screenshot of the tool follows:

I shall refer to the reshaped RMIM as a XUM (XML/UML Model).
Through all reshaping steps, the tool keeps track of the mappings between the original RMIM and the XUM. It allows the user to enter instance values for any property in the RMIM (or XUM). It can then produce the following outputs:

1. 
   The mappings between RMIM and XUM, in a table-like XML form (which can be read back into the tool to do further reshaping)
   
2. 
   A MIF file defining the XUM structure
   
3. 
   An OCL file describing the XUM class model – to be used by a tool to draw the class diagram
   
4. 
   An XML schema for the XML form of the XUM (not yet implemented)
   
5. 
   An exemplar XML message in the full RMIM-based XML ITS, using the instance values input by the user
   
6. 
   An exemplar XML message in the a XUM-based XML, using the same instance values
   

The overall operation of the tool is illustrated in the diagram:

The two exemplar XML files, XUM and RMIM-based, are semantically equivalent to one another.
The exemplar messages are limited as follows: wherever there is an association with maxCardinality = ‘*’ (i.e in the XML, and element with maxOccurs unlimited), the class/child element will occur only once in the example – because you cannot enter more than one exemplar value for any property into the tool.
In what follows, I shall use the term ‘RMIM instance’ to refer to an instance of the RMIM class model. This is a set of objects (instances of the RMIM classes) with allowed values for the properties of the classes, and with associations as allowed by the RMIM. You can picture it as a small connected network of objects. Similarly I use the term ‘XUM instance’ to refer to an instance of the XUM class model – a connected set of objects, etc….
A message instance in the XML ITS is a RMIM instance, turned into XML by the XML ITS rules. A XUM message instance is a XUM instance, turned into XML by the same simple set of rules.
The allowed steps in restricting an RMIM are:

• 
  Restrict the minimum and maximum cardinality of any property or association to a smaller subset of the line [0..1..*] (e.g [min..max] = [0..1] can be restricted to [0..0] or [1..1] )
  
• 
  Constrain any leaf property (= RMIM structural attribute, or leaf property within a V3 data type) to a fixed value
  

After an RMIM has been restricted in this way, any instance of the restricted RMIM is also an instance of the original RMIM.

The allowed steps in reshaping an RMIM to make a XUM are:

• 
  Collapse any association with maximum cardinality = 1, so that the two classes at either end of the association become the same class
  
• 
  Rename any class, property or association
  
• 
  Remove (unmap) any property with a fixed value
  
• 
  Unmap any property or association with minimum cardinality 0 (this is equivalent to restricting its cardinality to [0..0] )
  

It is not allowed to collapse any association with maximum cardinality = * (unlimited) because single-valued properties of the inner merged class would become multiple-valued properties of the merged class. When there are two or more such properties at the end of a collapsed 1:N association, essential information (about which value of one property goes with which value of the other property) would be lost in the collapse. So it is not allowed.

There are ongoing discussions about whether you should collapse an association if, by thus removing a class, you would remove some infrastructureRoot attributes. The reshaping tool does not prevent you from doing this.

2. Reshaping Data Types

As another part of the new ITS project, a revised set of V3 data types has been prposed (see earlier in this report). The reshaping tool is not yet aware of these revised data types. In stead, it lets you carry on the operations of restriction and reshaping down into the existing V3 data types.
An RMIM consists of a set of classes, with associations between them, and with properties. Some properties of RMIM classes may be multi-valued (i.e. they have maximum cardinality = ‘*’) and have V3 data types, which are complex structures in themselves.
The reshaping operations can be done either on parts of the RMIM proper (i.e. on classes described in the RMIM MIF file), or on classes which represent the structure of the V3 data types (taken from the data type schema). These are called ‘data type classes’.
Because we may want to do reshaping and simplification within a V3 data type, this structure is treated in a uniform manner with structure in the RMIM.
A value of a complex V3 data type is considered to be an instance of a data type class which is part of the XUM. This class may have ‘leaf properties’ which are simple strings and can be represented by an XML attribute; or they may have associations to other classes which represent part of the complex data type.
For instance, a value of the V3 data type ‘AD’ (an address) is represented by an instance of the data type class ‘AD’ which itself has leaf properties (nullFlavor, use, and isNotOrdered), and has associations to classes like ‘ad_city’ which parts of addresses. An association from class AD to class ad_city represents that the address can contain any number of ‘city’ address lines. A property ‘textContent’ of the class ad_city represents the text value of a city address line.
When an RMIM class has a property of type ‘AD’, this is represented as an association from the RMIM class to the data type class ‘AD’.

3.