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

RMIM Designer Documentation (DatatypeReleaseSupport)

From HL7Wiki
Revision as of 15:40, 8 October 2009 by Gwbeeler (talk | contribs)
Jump to navigation Jump to search
Overview   2010/11 Updates   VocabMIF   DataTypeReleases   BatchProcess   CommandLine   Errors/Install   Vis2002-3-7-10-13    

Introduction  (DataTypeRelSetByLoadedRIM ) ConversionWhenModelOpens ·  RoundTripConversionNote ·  BatchConversion ·  ConversionOptions


With the advent of HL7 Data Types Release 2, it became necessary to provide the ability to migrate a design from data types R1 to data types R2, and vice versa. This is possible because the RIM expresses a specific mapping to be followed, and, with one exception, this process can be reversed with no changhe in the base model.

Data Types Release Governed by RIM Loaded in RMIM Designer

The RMIM Designer actually has two "states" - one in which it supports only data types R1, and one where it supports only R2. These states are established when the RMIM Designer first loads a RIM from an HL7 Design Repository. Historically, all RIMs from RIM version 0.8 through RIM version 2.26 are bound to data types R1. RIMs with versions 2.27 and later are planned to be bound solely to data types R2. If the loaded RIM is based on Data Types R1, the RMIM Designer will only support that data type release, and vice-versa.

At any given time, the current state of the RMIM Designer can be determined by selecting Menu...HL7...About This selection displays an "About" window, and the second section lists the version of the RIM (and data types) that are loaded along with the version of the Vocabulary that is loaded.

Data Type Conversion on Opening a Model

Whenever an RMIM Design is opened, whether manually or as part of a batch process, the RMIM Designer first ascertains the data type release of the model. (This is determined by a document tag discussed elsewhere.) If the data type release of the model does not match the current state of the RMIM Designer, the model cannot be opened without converting the data types.

If the document was opened manually, the following dialog will be opened. (Batch processing is covered in a separate section.)

Dialog when data types do not match on model load.

As seen in the dialog, if the RMIM designer and Model data types do not match, the user has three choices - change the model, change the loaded data types, or "back-out - as:

  • Continue and convert the model to the appropriate data type release. (Select: Yes)
  • Reload the RMIM Designer with a new RIM whose data types match the model. (Select: No)
    Be advised that this option will also cause the Vocabulary to be re-loaded, and the size of the Visio application in memory will become quite large. Each vocabulary load consumes about 500 MB of memory.
  • Terminate the loading process (back out). (Select: Cancel)

At the end of the conversion process, there will be an "Error" dialog that lists each attribute of the model for which the data type specification is not a proper restriction of the RIM data type for that attribute. This is an advisory note to the user. The "improper" data type will be assigned to the attribute.

Note further, that this conversion process does not save the converted model. The user must be sure to do this manually after the conversion process.

Fidelity Of Round-Trip Conversions

By and large, a properly constrained model in data types release one should convert to a properly constrained model in data types R2, and return to its original settings when re-converted to data types R1. Known exceptions to this statement include the following. Each of the following sections reflects "conversion to" as R1 to R2, and "conversion back-to" as being R2 to R1

Conversion of CE to CD back-to CD

Data types R2 does not have a data type CE. Thus, all CE are converted to CD. When these are converted back-to R1, they will remain as CD unless the RIM data type in R1 is declared as CE, in which case, the back-to conversion will return the type to CE. Thus the only CE types that fail to round-trip correctly are those whose R1 RIM data type was CD and were subsequently constrained in the model to CE. In that case, when converted back-to R1, the will come back as CD.

Conversion of RTO to RTO<PQ,PQ> back-to RTO<PQ,PQ>

A single RIM attribute Role.quantity has (through RIM 2.28) a data type stated simply as RTO. This is apparently an error, as all documented use cases suggest it should be RTO<PQ,PQ>. The 4.5.5 release of the RMIM Designer automatically converts a model whose binding is still to RTO to the preferred value and leaves the preferred value when converting back-to R1.

Please Report Other Exceptions

Users are requested to report other exceptions to "Round-Trip Fidelity" as on the Gforge Bug Tracker for the Curent RMIM Designer. Although many may not be correctable, we will, at least, try to document them here.

Batch Conversions

The batch menu options are covered on the Batch Process Tab of this documentation. These conversions are available in both Visio 2002 and Visio 2003-7. In the latter Visio product, data type conversions are inextricably linked to conversions between Visio file formats.

Conversion Options

With the combination of data types releases and different Visio versions, as well as the addition of new code to document context conduction style for a model, there arose the need for somewhat greater control over the various conversion options. To this end, starting in release 4.5.1 (and extended in 4.6.6), a new menu item was added to the "HL7 menu" as Menu...HL7...Show Conversion Options to display a pane of such options. The pane appears like:

Conversion Options Pane from RMIM Designer

This (crude) pane contains true/false selections for five different conversion options. Each option has summary documentation on the pane itself, although somewhat more detail is provided below.

As they are changed, options are "saved" in the Hl7Visio.ini file in the HL7 shapes directory. The Close: button simply hides the options pane. The Reset to Defaults button will reset the five options to the values shown as "recommend" on the pane itself.

The first two of these options affect the process of upgrading designs from Visio 2002 to Visio 2003/7 and reverting them back to Visio 2002. (See Visio2002/2003-7 tab.)

The next two affect converting models between data types release R1 and release R2 (and vice-versa). (See DataTypeReleases tab.)

The final option disallows a value of "inferred (I)" as a context conduction style. Disallowing this option provides an easy way to detect all models for which an expressed method of context conduction has not been declared. (See 2010/11 Updates tab.)

Option: Enable Auto-Update from Vis2002 to Vis2003-7

As noted in the pane, determines whether Visio will automatically convert a "vsd" drawing file from Visio 2002 format to Vis2003-7 format when it is opened in Vis 2003-7. This update is necessary to cause the shapes to display correctly. A number of shapes, particularly the "arrow" classes appear to lose content when first viewed in Visio 2003-7


Option: Suppress Auto-Save of Converted File

As noted in the pane, Determines whether Visio will supress the automatic re-save of a VSD drawing after converting from Vis2002 to Vis2003-7. The automatic save, and a subsequent automatic re-open are part of the normal conversion process. Without these two steps, the shape representation does not "refresh" to a correct presentation. However, the save precludes being able to review designs from a read-only repository. For cases such as this, this opetion can be set "true".


Option: Allow Retain Flavors When Convert DT R2 to DT R1

As noted in the pane, if this option is "False", Visio will strip off data type flavors when reverting a model from data types R2 to data types R1. This is the preferred action for Universal ("UV") models, because data type flavors are usually added at the realm-specific level (or lower) rather than as part of universal designs.

RECOMMEND = "False" for universal (UV) designs.

Option: Block Add DT With Non-existing Base

As noted in the pane, Determines whether the data types processing code will refuse to add new data types whose "base" name is not in the relevant specification (R1 or R2). This does not preclude adding new flavors.


Option: Reject Inferred (I) Context Conduction Style

As noted in the pane, this option determines whether or not the "inferred (I)" context conduction style code can be set or retained in the entry point for a model. The methodology calls for one of three code values:

  • "C" designates the model uses the original conduction-indicator-based method of establishing context conduction, a method that was deprecated during 2010.
  • "V" designates the model uses the new vocabulary-based method of establishing context conduction as adopted during 2010.
  • "I" designates that the model does not explicitly establish context conduction. This designation is formally "discouraged."

As models evolve, many of them (particularly those developed before 2010) are using the "inferred (I)" designation. While there is an easy way to establish context conduction style, changing the designation once made is cumbersome. Switching this option from "false" to "true" will cause the RMIM Designer logic to automatically seek user approval to change the designation code for any model designated as "inferred."

The final option disallows a value of "inferred (I)" as a context conduction style. Disallowing this option provides an easy way to detect all models for which an expressed method of context conduction has not been declared. (See 2010/11 Updates tab.)

RECOMMEND = "False" for routine use.

Option: Set "Default" Conduction Style During Batch Processes

When a model for which context conduction style has not yet been defined is processed with one of the batch options, this option determines whether or not the batch process should assert the "default" conduction style as it proceeds. Note, this setting will have no impact on the designs if the batch process is not also "saving" the files. Processes that do not save files include "validation" and "graphic overlay extraction"; processes that do save files include "conversions to different Visio releases", "data types conversions" and "scan, update and save vocabulary constraints while doing graphic overlay extraction."