HTC Tools Roadmap

Introduction

The HL7 Tooling Collaborative (HTC) has been established with resource contributions from key HL7 stakeholders, to deliver significant benefits within 1 year of the project's initiation. This collaboration will enhance and integrate current initiatives by various stakeholders. A business model and project organisation, as well as a high-level technical architecture for tools, are described in separate documents.

At the request of the HTC, the HL7 Tooling Committee has undertaken to revise and extend this roadmap document to reflect a more complete picture of HL7 tools requirements. The extension is reflected here on the Wiki.

Tools 'vision'

In general, the HL7 / NHS Collaborative Tools Project envisions tooling that:

1. produces machine-processable artefacts, spanning through all stages of the message design cycle (requirements, design, implementation and testing)
2. supports end-to-end automated testing of interoperability solutions
3. standardises the type and quality of the information conveyed between each stage and between communicating organisations
4. produces coherent, traceable and versioned concepts from analysis to implementation
5. facilitates direct involvement / feedback in international standards and tools development, ensuring ongoing alignment of implementation specifications with industry standards, including HL7 V3
6. reduces message development time, allowing the automatic translation of message designs to supplier-specific formats
7. facilitates consistent workflows and project management / oversight
8. provides a framework for publishing documentation about the artefacts generated throughout the process.

Tooling 'Roadmap'

A potential summary view of tools required to accomplish the vision is provided in Figure 1.

Editors Please Note: If you wish to help by editing this diagram, there are two source forms available as Visio files. The first is the unmodified source file from HTC‎. The second is the file that generated the GIF below. It was taken from the HTC Word document and then cobbled together in Visio.

Figure 1. Summary of potential tools with flows representing general progression through message development and implementation stages. Feedback flows are not represented in this diagram. The gray arrows represent the areas documented with the documentation editing and management tools.

Description

A brief description of the function of each of the boxes in the diagram follows (in italics: the ??? person):

• Business Requirements Modeling Tools - (1) Enables the use of UML Business Process Modeling concepts to develop the initial components of a domain analysis model: A business process is an ordered collection of activities with a beginning triggered by an event that uses defined inputs (information and resources) to produce a specific output. (2) Enables the use of class and activity diagrams to further elaborate the information exchanges and interactions of interest that are depicted in a business process model.
• Terminology Management Tools - Russ Hamm
• Static Model Designer - Woody Beeler
• Dynamic Model Designer - Woody Beeler
• Schema Generator - Lloyd Mckenzie
• Example & Test Message Generator - Lloyd Mckenzie
• Message Tester - Lloyd Mckenzie
• Code Generator Frameworks - IS
• Documentation Editing & Management Tools - Woody Beeler
• Documentation Publisher - Woody Beeler
• Shared Artefact Repository - Jane Curry
• Design Analysis Tools - Jane Curry
• Artefact Configuration Management tool - Jane Curry

Dependencies

Some of the tools listed above have dependencies either on other tools (e.g. represented by input flows in Figure 1), or on design decisions required for other tools.

1. All tools must be able to easily interoperate and should be orthogonal. The interoperability layer that underpins this toolset is a prerequisite for all design.
2. The Static Model Designer must be able to accept input from the Business Requirements Analysis tool, as well as feedback from the Message Tester, and the Example & Test Message Generator.
3. The Dynamic Model Designer must be able to accept input from the Business Requirements Analysis tool.
4. The Schema Generator requires output from both the Static and Dynamic Model Designers
5. The Code Generator requires output from the Static Model Designer and Schema Generator
6. The Example & Test Message Generator requires the Static Model Designer and Schema Generator
7. The Message Tester requires output from the Static Model Designer, Schema Generator and Shared Artefact Repository (with stored Test Messages)
8. The Documentation Editing and Managing Tools provide support for collecting textual documentation about the Business Requirements and Model Designs.
9. The Documentation Publisher draws primary data from the Shared Artefact Repository and the Documentation Management Tools.
10. The Shared Artefact Repository needs clear guidelines on types/defining attributes of artefacts

Some of these prerequisites require greater definition than others.

Achieving the vision

In order to achieve the full suite of tools in the vision, the following high-level schedule is anticipated (presuming resources become available to support all listed sub-projects).

Completed tools by end of Year 1:

• Infrastructure components
• Shared artefact repository
• Business requirements modeller
• HL7 Model Designer
• Schema generator
• Example instance generator

Tools produced to be used within Year 1 and to complete by end of Year 2:

• Terminology tools
• Design analysis tools
• Message testers
• Code generator frameworks

Commercial models & licensing

Stakeholders will engage with the project in different ways, depending on their particular requirements and commercial interests. The following are proposed models.

NOTE: The following model elements are copied from the HTC Draft MOU, replacing the equivalent elements in the roadmap. As the Roadmap advances, this note paragraph should be dropped.

• Open Model. This model allows full sharing with no commercial obligations. All artifacts contributed in this way will be made available through Eclipse. Artifacts delivered in the Open Model may be freely used in packaged solutions developed under other models, where there may be commercial interests
• Consortium model. This model will allow for full sharing with a group of stakeholders. Artifacts may be licensed to other parties outside the consortium, on commercial terms agreed by the consortium.
• Closed model. Artifacts developed and shared according to the closed model will remain private to the Collaborative Member, who may then license the product to other parties.
• Tooling Vendor model. Artifacts developed under the Tooling Vendor model remain private to the Collaborative Member, who may then license them and optionally act as a broker and service provider for other stakeholder who wish to market their products develop in a non-open model

Tools and Proposed Commercial Models

A summary of tools and proposed commercial models:

Tool	Open	Consortium	Closed	Tool Vendor / OTS
Business requirements modeller				X
Terminology management*	X	X		X
Static model designer	X
Dynamic model designer	X
Schema generator	X
Code generator frameworks	X	X	X
Example instance generator	X
Message & interactions tester*	X	X	X
Documentation Editing & Management Tools	X
Documentation Publisher	X
Shared artefact repository	X
Design analysis	X
Artefact configuration management	X
Infrastructure components	X

* Different parts of these tools will have different modes of involvement. The common underlying infrastructure will be open, and extensions may be either open or developed under the consortium or closed models.