This wiki has undergone a migration to Confluence found Here
Difference between revisions of "HL7 Tooling Challenge"
Jump to navigation
Jump to search
| Line 1: | Line 1: | ||
| − | This page is to record information about the | + | 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]]<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 | + | ==[http://www.hl7.org/events/toolingchallenge.cfm Tooling Challenge 2014]== |
| − | ''' The following solution has been selected as the | + | ''' 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 <<need link>> | ||
| + | *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 [[:Category:V3_Methodology_Requirements|V3 Methodology Requirements]] | * Link to Requirements for MIF [[:Category:V3_Methodology_Requirements|V3 Methodology Requirements]] | ||
| Line 20: | Line 43: | ||
==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 | + | ** 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 | + | **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. |
| − | ** Demonstrated application on more tools will be considered an advantage | + | **Demonstrated application on more tools will be considered an advantage |
| − | ** The UML profile is well documented and easy for newcomers HL7 V3 to understand | + | **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 | + | **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 | + | * 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, | + | * 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 | + | * 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 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. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | * | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 21:05, 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 <<need link>>
- 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.
- Link to Requirements for MIF V3 Methodology Requirements
- Link to MIF Schemas on Gforge
- Link to "starter" profile in XML
- Link to example model
- Sparx Systems press release
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.
