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

RMIM Diagram Representation

From HL7Wiki
Jump to navigation Jump to search


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.


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

Eclipse 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. - Color coding, shadows, CMETs, and additional attribute content will be supported - Arrow-shaped and recusive boxes are unlikely to be supported - Support for other graphical effects (stubs, entry points, subject areas, choices) are not known -- (Rajie, can you clarify this?)

Standard UML syntax

<Insert UML profile here>

Sample Traditional diagram

<Insert diagram of Clinical Statement here>

Standard UML diagram (same model)

<Insert diagram of UML-ized Clinical Statement here>

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 'straight' (or 'straighter') 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]


We will discuss this on the January 30th conference call