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

Difference between revisions of "HL7 Tooling Challenge"

From HL7Wiki
Jump to navigation Jump to search
 
(18 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page is to record information about the first HL7 Tooling Challenge.  The intent of this initial challenge is to produce tooling to help implementers implement V3 standards which are expressed in Model Interchange Format.  
+
This page is to record information about the 2014 HL7 Tooling Challenge.  The intent of this initial challenge is to produce a design specification for a tool that can be used to create RIM-derived information models  
 +
*Award: $4000
 +
*Submission Deadlines: May 2, 2014 - Deadline to declare intent to participate
 +
*July 1, 2014 - submission deadline
 +
*Winner announced: September 16, 2014 during the HL7 Plenary and Working Group Meeting
  
Return to [[Tooling Work Group]]
 
  
 +
Return to [[Tooling Work Group]]<br/>
 +
See the [http://www.hl7.org/events/toolingchallenge.cfm official Tooling Challenge page] on the HL7 web site
  
 +
==[http://www.hl7.org/events/toolingchallenge.cfm Tooling Challenge 2014]==
 +
''' The following solution has been selected as the 2014 HL7 TOOLING CHALLENGE'''
 +
*Evaluate and define in detail the design of a method for using an off-the-shelf (OTS) UML tool for maintaining HL7 V3 artifacts. The design to be provided should allow a developer, following that design, to create a design tool that would meet HL7’s needs.
 +
**The goal is to produce a design specification for a tool that can be used to create RIM-derived information models. The specification should include an HL7-profile in which each class of the HL7 Reference Information Model (RIM) becomes a stereotype that can be “drag-and-drop”(ped) into the new model.  We anticipate that this will require defining an updated HL7-UML profile that will be part of the design.  As with the prior Tooling Challenge, the technical foundation for HL7 information models is based on the HL7 Model Interchange Format (MIF).
  
==Tooling Challenge 2012==
 
''' The following solution has been selected as the FIRST HL7 TOOLING CHALLENGE'''
 
*Produce a UML Profile for MIF Static Models - This is a task so that other modeling tools have a chance to be configured to understand MIF
 
**Document a UML Profile for the semantics in the MIF representation of the RIM and other derived models - identifying those concepts that cannot be expressed in UML Profile language to provide to OMG for possible extension of UML
 
**Using the resulting UML Profile, adapt Enterprise Architect to express the proper HL7 stereotypes as a proof of concept. An example would be enumerations for the drop down stereotypes for a concept domain, code system or value set. A further example would be a class could be an Act, Entity, or Role
 
  
===Background===  
+
To qualify for the prize, a submitter must include within the design specification, the following capabilities.  The specified solution:
 +
*Must enable the resulting tool: to accept a model expressed in MIF; allow modifications thereto; and to express the result in MIF. Notes:
 +
**If required, the design may propose changes or extensions to the HL7 Model Interchange Format (MIF) on which this effort is based.
 +
**The Profile might be generated by transforming the HL7 RIM, expressed in MIF.
 +
*Must accommodate replacement of the HL7 RMIM designer in Visio (see documentation on HL7 Wiki at http://wiki.hl7.org/index.php?title=RMIM_Diagram_Representation)
 +
*Must include a functional decomposition of the capabilities as part of the design specification.
 +
*Must describe development of an attribute selection and constraint dialog like that used in the HL7 RMIM Designer and in the [https://projects.openhealthtools.org/sf/projects/staticmodeldesigner/ SMD tool]
 +
*Must show how fixed property values from the RIM (like “isDocumentCharacteristic”) would be encoded in the updated profile.
 +
*Must include an updated UML profile that can be applied to Enterprise Architect such that EA can produce class models that represent the semantics described in the UML profile.
 +
 
 +
 
 +
===Background===
 +
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. <br/>
 +
In the past, HL7 has had a policy that all RMIMs published in universal ballots must be documented using the "Visio" style format. While some committees had requested permission to document their models using standard UML tooling, this request was denied. Initially, the rationale was to ensure consistency of presentation as well as ensuring all artifacts could be maintained by a common set of tooling. As time went on, the rationale expanded to include the inability to express the UML models in MIF, which was necessary to produce the other artifacts published by HL7. <br/>
 +
UML class diagram notation is a widely adopted standard that is nowadays taught in many universities and is understood by many implementers of HL7 standards. A well-defined relationship to UML standard notation would help promote adoption by the HL7 user community. If UML class diagram notation is used as the baseline for HL7, then the unique HL7 extensions may be specified as optional or recommended notational decorators. Some UML tools may then include an alternative class diagram view using these HL7 decorator extensions. The primary difference is in displaying additional attribute metadata and choice groups. HL7 extended metadata is retained in UML stereotypes and is viewable in property view editors. The choice group representation in UML is nearly identical to that in MIF (choice items as class specializations). The standard UML class diagram, as shown below, displays the choice group content as represented in MIF. <br/>
 +
With such, HL7 Visio RMIM Designer is slated to be retired in the next year or two as HL7 moves to a replacement tool. At present, the expected replacement is the Eclipse-based Static Model Designer.
 +
 
 +
 
 +
 
The Model Interchange Format is organized as a set of XML Schema files that describe the key metadata to express published standards.  The MIF is used to transform the approved models as serialized XML files.  The MIF was designed to meet the requirements of the V3 Methodology to express concepts that could not be expressed in XMI.
 
The Model Interchange Format is organized as a set of XML Schema files that describe the key metadata to express published standards.  The MIF is used to transform the approved models as serialized XML files.  The MIF was designed to meet the requirements of the V3 Methodology to express concepts that could not be expressed in XMI.
** Link to Requirements for MIF [http://wiki.hl7.org/index.php?title=Category:V3_Methodology_Requirements]
+
* Link to Requirements for MIF [[:Category:V3_Methodology_Requirements|V3 Methodology Requirements]]
 +
* Link to [http://gforge.hl7.org/gf/download/frsrelease/649/7965/hl7_mifschemas-2.2.0.0.zip MIF Schemas] on Gforge
 +
* Link to [http://wiki.hl7.org/images/1/11/HL7-rimCombinedProfile.zip "starter" profile in XML]
 +
*Link to [http://gforge.hl7.org/gf/download/frsrelease/33/37/hl7_umlprofile-1.0.0.zip example model]
 +
*[http://www.sparxsystems.com/press/articles/toolingchallenge.html Sparx Systems press release]
  
 
==Judging Criteria==
 
==Judging Criteria==
 
*  The criteria on which the submissions will be judged will be:
 
*  The criteria on which the submissions will be judged will be:
** The proposed UML profile will be reviewed by representatives from the HL7 Tooling Work Group to ensure that it is a valid and complete expression of the extensions to UML that are part of the HL7 MIF representation of static models
+
** The proposed tool design specification will be reviewed by representatives from the HL7 Tooling Work Group to ensure that it will represent a valid and complete expression of the extensions to UML that are part of the HL7 MIF representation of static models  
** The proposed UML profile will be reviewed by an OMG representative to ensure it's validity
+
**The proposed UML profile will be reviewed by an OMG representative (Richard Soley for the 2013-2014 Challenge) to ensure its validity and its interoperability with other OMG standards
** The proposed UML profile is successfully applied to Enterprise Architect such that EA can produce class models that can represent the semantics described in the UML profile - documenting any difficulty in applying the profile.
+
**The proposed UML profile is successfully applied to Enterprise Architect such that EA can produce class models that can represent the semantics described in the UML profile - documenting any difficulty in applying the profile.  
*  The AWARD will be given to the first team submitting a validated UML profile and corresponding UML Profile applied to Enterprise Architect. Announcement of the successful team is desired to be at the September 2012 Working Group during the plenary. If no team submits a successful solution the contest will continue.  
+
**Demonstrated application on more tools will be considered an advantage
 +
**The UML profile is well documented and easy for newcomers HL7 V3 to understand
 +
**How extensible the profile is in order to keep the profile up with changes in the methodology
 +
*  An intent to submit a solution to the HL7 Challenge should be announced to the Tooling listserve by the May Working Group Meeting.  A discussion with potential submitters during the May Working Group Tooling sessions should be supplemented by a webinar for participants not attending the WGM.
 +
*  Submissions will be accepted until July 1, 2014
 +
*  The AWARD will be given to the team submitting the best solution - in case of more than one team submitting an equally valid solution, the team submitting a validated UML profile first will be accepted. Announcement of the successful team is desired to be at the September 2014 Plenary and Working Group during the general session. If no team submits a successful solution the contest will continue.
  
 
==Additional objectives==
 
==Additional objectives==
*The following tooling objectives would also add value, and will be used to solicit existing or contributed tools - and potentially be the subject of a different HL7 Tooling Challenge in the future.
+
The design should
*# Produce a MIF to XMI XML transform consistent with the updated UML Profile.
+
*Describe the method to “hide” the attributes that are not required and that one wishes to exclude from a derived model (Each RIM attribute would be part of its relevant stereotype)
*# Produce a viewer that can browse MIF schemas (Meta level)- this task makes it easier to understand the relationship among the MIF files and their elements.
+
*Describe how one would distinguish between class “properties” (from the profile) and class “attributes”.  The latter need to display as class attributes in any RIM-derived UML model
*# Produce a viewer that can browse MIF based models (model level)- this task makes it easier to understand the serialized models expressed in MIF XML.
+
*Recommend whether the design needs a “stereotype” for each RIM attribute as well, and/or sub-stereotypes based on the characteristics of attributes, such as a stereotype for encoded attributes.
*# Produce a viewer that can browse instances from MIF based models (instance level) - this task makes it easier to evaluate instances based on serialized MIF models.(there is some work that already exists)
 
*From RIMBAA, which has its own tools page at [[Tools for RIM based software development]]: #1 is certainly a key issue for software developers. We already have an example of #2 as an educational tool made available by a commercial party, #4 is probably already (mostly) availble as the Instance Editor. The MIF based 'evaluation' of instances, without validating the instance, doesn't sound terribly attractive.
 

Latest revision as of 21:11, 7 January 2014

This page is to record information about the 2014 HL7 Tooling Challenge. The intent of this initial challenge is to produce a design specification for a tool that can be used to create RIM-derived information models

  • Award: $4000
  • Submission Deadlines: May 2, 2014 - Deadline to declare intent to participate
  • July 1, 2014 - submission deadline
  • Winner announced: September 16, 2014 during the HL7 Plenary and Working Group Meeting


Return to Tooling Work Group
See the official Tooling Challenge page on the HL7 web site

Tooling Challenge 2014

The following solution has been selected as the 2014 HL7 TOOLING CHALLENGE

  • Evaluate and define in detail the design of a method for using an off-the-shelf (OTS) UML tool for maintaining HL7 V3 artifacts. The design to be provided should allow a developer, following that design, to create a design tool that would meet HL7’s needs.
    • The goal is to produce a design specification for a tool that can be used to create RIM-derived information models. The specification should include an HL7-profile in which each class of the HL7 Reference Information Model (RIM) becomes a stereotype that can be “drag-and-drop”(ped) into the new model. We anticipate that this will require defining an updated HL7-UML profile that will be part of the design. As with the prior Tooling Challenge, the technical foundation for HL7 information models is based on the HL7 Model Interchange Format (MIF).


To qualify for the prize, a submitter must include within the design specification, the following capabilities. The specified solution:

  • Must enable the resulting tool: to accept a model expressed in MIF; allow modifications thereto; and to express the result in MIF. Notes:
    • If required, the design may propose changes or extensions to the HL7 Model Interchange Format (MIF) on which this effort is based.
    • The Profile might be generated by transforming the HL7 RIM, expressed in MIF.
  • Must accommodate replacement of the HL7 RMIM designer in Visio (see documentation on HL7 Wiki at http://wiki.hl7.org/index.php?title=RMIM_Diagram_Representation)
  • Must include a functional decomposition of the capabilities as part of the design specification.
  • Must describe development of an attribute selection and constraint dialog like that used in the HL7 RMIM Designer and in the SMD tool
  • Must show how fixed property values from the RIM (like “isDocumentCharacteristic”) would be encoded in the updated profile.
  • Must include an updated UML profile that can be applied to Enterprise Architect such that EA can produce class models that represent the semantics described in the UML profile.


Background

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.
In the past, HL7 has had a policy that all RMIMs published in universal ballots must be documented using the "Visio" style format. While some committees had requested permission to document their models using standard UML tooling, this request was denied. Initially, the rationale was to ensure consistency of presentation as well as ensuring all artifacts could be maintained by a common set of tooling. As time went on, the rationale expanded to include the inability to express the UML models in MIF, which was necessary to produce the other artifacts published by HL7.
UML class diagram notation is a widely adopted standard that is nowadays taught in many universities and is understood by many implementers of HL7 standards. A well-defined relationship to UML standard notation would help promote adoption by the HL7 user community. If UML class diagram notation is used as the baseline for HL7, then the unique HL7 extensions may be specified as optional or recommended notational decorators. Some UML tools may then include an alternative class diagram view using these HL7 decorator extensions. The primary difference is in displaying additional attribute metadata and choice groups. HL7 extended metadata is retained in UML stereotypes and is viewable in property view editors. The choice group representation in UML is nearly identical to that in MIF (choice items as class specializations). The standard UML class diagram, as shown below, displays the choice group content as represented in MIF.
With such, HL7 Visio RMIM Designer is slated to be retired in the next year or two as HL7 moves to a replacement tool. At present, the expected replacement is the Eclipse-based Static Model Designer.


The Model Interchange Format is organized as a set of XML Schema files that describe the key metadata to express published standards. The MIF is used to transform the approved models as serialized XML files. The MIF was designed to meet the requirements of the V3 Methodology to express concepts that could not be expressed in XMI.

Judging Criteria

  • The criteria on which the submissions will be judged will be:
    • The proposed tool design specification will be reviewed by representatives from the HL7 Tooling Work Group to ensure that it will represent a valid and complete expression of the extensions to UML that are part of the HL7 MIF representation of static models
    • The proposed UML profile will be reviewed by an OMG representative (Richard Soley for the 2013-2014 Challenge) to ensure its validity and its interoperability with other OMG standards
    • The proposed UML profile is successfully applied to Enterprise Architect such that EA can produce class models that can represent the semantics described in the UML profile - documenting any difficulty in applying the profile.
    • Demonstrated application on more tools will be considered an advantage
    • The UML profile is well documented and easy for newcomers HL7 V3 to understand
    • How extensible the profile is in order to keep the profile up with changes in the methodology
  • An intent to submit a solution to the HL7 Challenge should be announced to the Tooling listserve by the May Working Group Meeting. A discussion with potential submitters during the May Working Group Tooling sessions should be supplemented by a webinar for participants not attending the WGM.
  • Submissions will be accepted until July 1, 2014
  • The AWARD will be given to the team submitting the best solution - in case of more than one team submitting an equally valid solution, the team submitting a validated UML profile first will be accepted. Announcement of the successful team is desired to be at the September 2014 Plenary and Working Group during the general session. If no team submits a successful solution the contest will continue.

Additional objectives

The design should

  • Describe the method to “hide” the attributes that are not required and that one wishes to exclude from a derived model (Each RIM attribute would be part of its relevant stereotype)
  • Describe how one would distinguish between class “properties” (from the profile) and class “attributes”. The latter need to display as class attributes in any RIM-derived UML model
  • Recommend whether the design needs a “stereotype” for each RIM attribute as well, and/or sub-stereotypes based on the characteristics of attributes, such as a stereotype for encoded attributes.