RMIM Diagram Representation

Introduction

This page is intended to capture discussion and considerations related to whether the next generation of the Static Model Designer needs to retain support for the "traditional" HL7 static model diagramming syntax, and if so, what sort of support is necessary.

Background

HL7 (Visio) Diagrammatic Representation

HL7 has had a specialized diagrammatic representation used to render static models such as DMIMs (DIMs) and R-MIMs (CIMs). This representation includes: - arrow-shaped boxes and "recursive corner" boxes for relationship classes. - surrounding dashed-line "boxes" to designate choices - a box with an out-going arrow to designate entry points - specialized shapes to designate CMETs and shadows - special boxes to represent subject areas and subject-area references - distinct shapes for comments and constraints - color-coding to reflect RIM derivations - additional attribute and association characteristics including isMandatory, conformance, default and fixed values, business names, vocabulary bindings, update mode, etc. The "standard" UML syntax uses none of these conventions and does not expose some of this information

OHT_-_NHS_sponsored_Static_Model_Designer Eclipse Static Model Designer (SMD) Diagrammatic Representation

The next generation of the static model designer developed by the NHS currently uses underlying Eclipse graphical design features that do not support the HL7 specialized diagramming syntax. Some elements are or will be supported. Some are not yet supported. Some are not planned to be supported, at least in the "design" view. There's the possibility of using automated layout to generate a v3 view, but this possibility is likely to be technically challenging and does not have a high probability.

Standard UML syntax

<Insert UML profile here>

Sample Traditional diagram (Visio)

<Insert diagram of Clinical Statement here>

New SMD diagram (Eclipse)

The semantic concepts are expressed as follows:

• Attributes

Same as before, properties such as mandatory, fixed/default values, conformance, datatype and vocab info displayed as before.

• Entry point

Same as before, except non-orthogonal connection is also supported

• Classes

Color coded based on archetype. Naming is supported according to the HL7 formal naming algorithm. All classes are box shaped. The Visio style arrow shaped boxes are represented as a class with two associations, therefore can be connected in any angle.

• Associations

Player, scoper and regular associations are the same as for the Visio style diagramming. Formal naming is supported. In addition traversability is also indicated on the associations. Recursive connections are simply pointing back to the source class. Directionality is maintained, for example directionality of ActRelationships (what's a subject of what) is immediately visible.

• Choices

Same as before in the Visio style designer. Choice within choice is supported.

• Annotations

Annotations are supported, note and constraints are displayed as "sticky notes" in different colors.

• CMETs

Will be supported in the second phase of the project.

• Templates

Will be supported in the second phase of the project.

Comments

• Looks pretty good actually. 2 comments: what's with the html control elements? And with regard to space, does it have to laid out with so much space? Can't we diagram with the same density as the existing diagrams? --Grahamegrieve 11:23, 16 January 2009 (UTC)
  • 1. The annotations within the diagram are handled as plain strings (could not integrate a browser in the sticky notes ;-). However, these annotations are edited using a rich text editor as html (formatting buttons, etc..). As for the spacing, the user can lay-out or rearrange these artefacts in a more compact fashion if needed. Bbanfai

Pros and cons

Benefits of the 'traditional' syntax

1. Extremely space-efficient. Diagrams can be fit on a page or two with little white-space and lots of information
2. "Important shapes" like Act, Entity and Role stand out more than Act-Relationship, Participation and RoleLink
3. Directionality of ActRelationships (what's a subject of what) is immediately visible
4. Names of relationship classes (e.g. Subject2, Subject3, Subject 24) that don't appear in the instances don't clutter up the model and annoy people
5. Choices focus on the concrete classes, not the irrelevant abstract ancestors
6. Serialization mechanism made clear through presence or absence of cardinality
7. Significant HL7 familiarity with syntax
8. Significant migration effort
9. All existing published and balloted static models use the old syntax and would require conversion to move
10. All of our existing documentation (e.g. V3 Primer), presentations, etc. use the old syntax

Benefits of the new Eclipse SMD syntax

1. This is a modeling tool, therefore the diagram is model 'aware'. For example it does not allow different archetypes to be added to a Choice.
2. Better supported by Eclipse technologies
3. Classes can be connected in any angle, more compact models, therefore no shadow classes are necessary
4. Auto-layout algorithms can be applied
5. Arrow shaped classes are displayed as they really are: a class with two associations. Directionality of ActRelationships (what's a subject of what) is immediately visible.
6. More familiar to the non-HL7-initiated, in particular implementers

Benefits of the 'straight' UML syntax

1. Eclipse structure supports it out-of-the box
   1. Supporting the HL7 custom syntax would require substantial customization
   2. Increased cost, risk of bugs
   3. Ability to take advantage of new features added by Eclipse over time
2. More familiar to the non-HL7-initiated, in particular implementers
3. Helps better expose content from a UML modeling perspective

Additional Considerations

1. MIF supports capturing multiple graphical renderings of a single model. Specifically, it can support both standard UML and traditional HL7 diagrams for a single model
2. If we support multiple renderings and don't have auto-layout, committees would need to edit layouts in both styles that would mean increased work
3. If we go with an auto-layout route, it's probably easier to do auto-layout of traditional UML than non-traditional, seeing as it's not space-efficient anyhow and the odds of off-the-shelf auto-layout software for standard UML is much higher than for the HL7-specific syntax

Other Discussion

[Fill in whatever comments/issues/concerns you have that don't fit above]

Resolution

We will discuss this on the January 30th conference call