HTC Tools Roadmap

Introduction

The HL7 Tooling Collaborative 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.

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.

A potential summary view of tools required to accomplish the vision is provided in Figure 1. The flow indicated with arrows represents the progression through stages of the process. Feedback flows are not represented in this diagram. Figure 1. Summary of potential tools with flows representing general progression through message development and implementation stages

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 HL7 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 Code Generator requires output from the HL7 Model Designer and Schema Generator
4. The Example & Test Message Generator requires the HL7 Model Designer and Schema Generator
5. The Message Tester requires output from the HL7 Model Designer, Schema Generator and Shared Artefact Repository (with stored Test Messages)
6. 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:

Proposed Models

Tool	Open	Consortium	Closed	Tooling Vendor / Off the shelf
Business requirements modeller	.	.	.	X
Terminology management *	X	X	.	X
HL7 model designer	X	.	.	.
Schema generator	X	.	.	.
Code generator frameworks	X	X	X	.
Example instance generator	X	.	.	.
Message & interactions tester *	X	X	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.