Tooling Tactical Steps

Background

In discussions earlier this month, we outlined current structure of HL7 tools -- their strengths, weaknesses, and functions; and the likely path to a future set of tools. to meet the needs of both HL7 itself (as a developer of standards) and of those implementing HL7 specifications. The objective was address two target requirements. The first of these is for tools to support the development and production of HL7 specifications, which has been the primary focus of HL7-sponsored tooling since 2000. The second set of requirements is to provide for a set of tools that facilitate and promote the implementation of HL7 Version 3 specifications in the healthcare marketplace.

A number of "diagrams" were developed, that are included here. The discussion was wide ranging, including a detailed review of the genesis of most of the current HL7 tools, tracing back as to the mid-1990s.

Notation on ANT (process scripting tool)

Many of the current HL7 publishing processes rely upon a command scripting program known as ANT (Another Neat Tool). ANT is widely used in software development to manage the process of compiling, documenting, and publishing software products from source code. There is support editing and running ANT scripts in many software development environments, including Eclipse.

ANT is a scripting language that allows one to manage a suite of files, and generate derivative file products using such things as XML transforms (XSLT), file concatenation, file renaming, file copying and file moving, etc. The scripts consider the dependency and creation sequence of each file, and limit the work done to only those areas that need updating. (For example, if a particular source file is older than the HTML file that was generated by transforming that source file, it is not necessary to run the transform a second time. However, if the source file is more recent, the script will remove the existing output file and produce a new one.) Using mechanisms such as this, as well as declared dependencies of one process upon another, one can build a very rich production environment out of the core elements.

In order for a particular external process to be usable with ANT, the external process must either be a Java implementation (as the XML transform engines are) or it must be able to be executed from the "command line" of the operating system. In HL7s case, a number of the tools (principally the Visio RMIM Designer tool and those functions dependent upon RoseTree) have been coded with command-line invocations that allow the common HL7-required functions to be invoked with ANT. Later in this document, particular functions will be listed as having been ANT enabled, if such a command-line interface is available for executing the function.

Current Tooling Environment

Figure A, the Current Tooling diagram lays out the structure of the current HL7 tools, in broad terms. This diagram depicts of today's the tools and flow that underlie the development and publication of the Version 3 RIM-based specifications.

Although Figure A is drawn from the perspective of the HL7 developer, it is expected that the evolution of implementation support tools will stem from this product suites currently in use, because many of the activities involved in standards development are repeated, albeit with a different perspective, as implementations are planned, designed and executed.

Work Group Deliverables

The left-hand column of Figure A shows the "deliverables" that are created by the developers (Work Groups) and that are the source for the HL7 publishing process. Each of these deliverables is created with a particular development tool (discussed below) and produces a specific output file that is fed to the processes and tools in the other columns. The items in this column are as follows:

• Domain Content in a Publication Database (PubDb) - This deliverable is both a database, and the "tool" on which the content is developed. This Access database holds the complete textual and structural definition of one or more HL7 "domains". The database uses Access forms and the relations between the various database tables to define and control the structure of the domain information content. The required structure is, in turn, based on the specification of those artifacts in the original HL7 Message Development Framework. Developers use this database (along with adjunct tools) to define their ballot content, including all of the textual descriptions of the artifacts. The database itself is delivered to HL7 for use in publishing.
• Static model designs - The static model designs for particular domain are currently created in the HL7 RMIM Designer implemented in Visio. The functionality is provided through HL7-specific design templates that hold graphic patterns and VBA (Visual Basic for Applications) programs that work in concert with dynamic link libraries (DLL) provided as part of the RoseTree tool. This software packages creates a "drag-and-drop" design environment for developing UML static models that: are rendered in the HL7-preferred graphic style, conform to the HL7 Methodology, and are "proper" refinements from the HL7 Reference Information Model (RIM). The results of the static, design process are delivered to publishing in one of two forms:
  1. A pair of files, one in the Visio VSD format, and an HL7-specific XML file of the content. These two files together express the complete design for a single "Message Type".
  2. A "Design Repository" and a Visio VSD file. A number of the older static model designs, were stored by the Visio RMIM Designer (using RoseTree DLLs) into an Access design repository. This mode of publication is required if a particular RMIM or HMD contains more than a single "Message Type". In that circumstance, Work Groups deliver to the publishing process the design repository that holds the HMD specification, as well as the Visio VSD file.
• Design Repository is the Access data base originally designed to house all Version 3 artifacts. At present, its primary function is to serve as the “Source of Truth” for the RIM and Vocabulary Model. It also has a secondary function to house a sub-set of the V3 static models that are saved in the repository by RoseTree. Both the the V3 Generator and the Publishing Process are dependent upon XML files "extracted" from the Design Repository, by RoseTree. At present, this process is the primary method of capturing and documenting the Vocabulary Model in a core MIF instance. (The process of "managing" the RIM is not shown in this diagram.)
• Vocabulary maintenance is the process whereby changes are made to the Vocabulary Model stored in the Design Repository. If present, the primary mechanism involves the documentation of required changes in the HL7 Vocabulary Maintenance Language, and the application of these changes through a Java program that links to the Design Repository using CTS-I.
• Other graphics - There are numerous other graphics that Work Groups create, over and above the static models. Included amongst these are the interaction "ladder diagrams" that illustrate the interactions documented in a particular storyboard; topic-specific or domain-specific diagrams to illustrate the content of the specification; etc. These are delivered to publishing as either a graphic file (GIF or JPEG), or as Visio VSD files. In the latter circumstance the publishing process will extract the requisite GIF or JPEG file.
• Other distribution content - A few of the domains have additional material, frequently expressed in Adobe PDF format, to be included with their material. These are usually simply documents that are linked into the text. These are received as files in a form that can be linked-to from the publication with no further change.
• V3 Specifications Maintained Solely in XML. This source represents the management of a set of HL7 Version 3 specifications that are currently documented in XML directly by their authors. The current XML format for these other specifications is one defined by HL7 and based upon a document type definition used by the W3C organization in publishing its standards.

  Examples of documents that are maintained in this format are: the Data Types specifications; the Version 3 Guide; the HL7 Facilitators Handbook; specifications of the Implementable Technology Specifications; etc.

• Standard Artifact Repository is a concept that has been central to the HL7 V3 methodology from the beginning. This notion is simply that all of the artifacts defined as part of V3 will be maintained in a common repository that is managed by HL7. This repository serves both as the "source of truth" for V3, and as a source that can be queried and reported against for managing the HL7 processes. Until recently, he Pub DB's and Design Repositories could be merged across domains, linked together, and used to accomplish the query/reporting capability mentioned above. As more content has moved to MIF files, however, this capability no longer exists.

Notation on Artifact Status

Each artifact within an HL7 ballot, has an associated "ballot status" that designates whether that artifact is one of the following -- a Normative artifact (within a DSTU or Normative standard) and belonging to a particular release of the specification; under ballot as a Normative document (DSTU, or Normative ballot); presented as "Reference" material for the ballot; or, presented as "Draft For Comment". An artifact may have its status asserted individually, or it may inherit its status from its parent topic within a domain, or from the domain as a whole.

In today’s environment, the status of each artifact affects the identifier used to represent that artifact. Thus, when compiling files from multiple sources, it is critical to know the defined status (in the context of this ballot) for each artifact. At present, the publication database that holds the definition for each artifact is considered to be the "source of truth" for the status of that artifact.

Moreover, wherever a design is “dependent upon” another design (uses or references it), that dependency is documented in the publication database, and this documentation is the "source of truth" for such dependencies.

Final, Packaged Results

The right-hand side of Figure A represents the publication package that results from processing the source provided by the Work Groups (as listed on the left). This is generally seen in the HL7 environment as an "HTML package" -- the ballot site published for each ballot cycle. In truth, the publication package is somewhat larger, as the downloadable archives associated with the ballot site provide for the distribution of a variety of source and derivative files, including schema files, Model Interchange Format (MIF) files, source static model designs, etc.

The middle three columns show the steps necessary to process the Work Group-supplied material (left column) into the final package (right column).

Initial File Preparation

The second column represents a series of smaller tasks necessary to extract individual files from the submitted content or convert those files to a form that can indeed be used by the ANT-defined processes for the HL7 Version 3 Generator, and the HL7 Publishing process. The steps are designated with an arrow with “Ext” in it. Reading from top to bottom, these steps are:

• Publication Database Extract ("dynamic model" file). The contents of the publication database are extracted into what is known as the "dynamic model" XML file format, using the HL7 "Publishing Widget" based on RoseTree DLLs. This extraction process is ANT enabled, and can be invoked to process a batch of publication databases (one from each workgroup) with a single invocation. The "dynamic XML" files are then treated as source files to the V3 Generator.
• Extraction of Static Model Graphics and Overlays In order to publish the static models, HL7 requires that a visual graphic of the static model be produced along with an HTML "map" overlay that will allow the figure to be "clickable". (A “clickable” graphic is one in which graphic elements hold a hyper-link such that, for example, clicking on a particular class in the diagram will link to a table that defines that class in detail.) The process for generating clickable graphics and the corresponding HTML map are managed in the Visio VBA software of the RMIM Designer. This capability has been ANT enabled in order that a batch of Visio "VSD" files can be processed in a single pass.
• Design Repository Extract (static model “HMD” files) If static model designs are provided in a design repository (because there are multiple "Message Types" defined for each RMIM), RoseTree is used to extract this content from the design repository, producing "HMD" files. This extraction process has also been ANT enabled.
• Conversion of "other graphics" The conversion of "other graphics" from Visio (VSD) to a graphic (GIF or JPEG) format is a manual process that has not been automated, and for which no plans to automate have been expressed.

V3 Generator Processing

The third column in Figure A represents the steps executed with the V3 Generator. This particular tool is described in greater detail below. In simple terms, the generator is a suite of functional capability defined with ANT-scripts.

V3 Generator Source

The V3 Generator accepts (requires) the following source files:

• CMET definitions and ballot status in a txt file;
• Dynamic Model XML files extracted from the Publication Database.
• "HMD" files (if any) extracted from the Design Repository;
• Visio-produced static model XML files (if any) produced from the RMIM Designer. (Note that a given static model must be represented by either an HMD file, or a Visio XML file, but not both. The V3 Generator is not particularly astute at spotting such duplication, and the presence of two files will inevitably cause errors.)
• A series of "core" specifications such as the RIM, vocabulary content, datatype specifications, etc. These are presented to the generator in either idiosyncratic XML format, or as "core MIF" files.
• Configuration files that specify the functions to be performed by the generator, and define the properties for the overall generation process;
• Example Generator Source data and configuration files that are used in defining a set of instance examples based upon the static models submitted for generation.

V3 Generator Outputs

In turn, the V3 Generator produces a series of output files, most in XML format. These include:

• Schemas (XML schemas) for each of the static model designs, and the interactions specified in the publication database;
• HTML files that represent a tabular perspective or table view of each static model design;
• Comma-separated-value (CSV) files for Excel that express each static model and HMD. [A separate Excel-based process that has not been ANT enabled, is used to convert the Excel CSV files into a complete Excel "XL S" format for use in the ballot publication. Although this conversion is initiated manually, it does provide for a batch capability that will process of all of the CSV files from a single generator run at the one time.]
• Model Interchange Format (MIF) files representing each static model and interaction included in the specification. These are currently prepared in both the older MIF 1.0 schema format, and the current MIF 2.1.3 schema versions.
• Various quality assurance reports and summary content files for use in assessing and managing the ballot process.

Publishing Processes for Ballots and Normative Editions

The fourth column from the left represents the publication process in which the source files from the right are brought together to produce the overall publishing package. Again, this is a series of processes that has been ANT-defined and takes advantage of the transform capabilities of the ANT engine.

For source files, these publishing processes consume the following content:

• The schemas from the generator;
• The dynamic XML files from the publication database;
• The tabular HTML expression of static model designs for the generator;
• The Excel XLS files generated from the generator source;
• The Visio-generated "clickable" graphics and their corresponding HTML maps;
• The graphic representations of the other graphics as GIF or JPEG);
• The "other distribution" files;

Major components and functions of V3 Generator

Figure B is a representation of the major components that make up the Version 3 Generator. As noted previously, the generator is a series of ANT-driven processes that manage the transformation and configuration of a set of disparate source files into a coherent set of Model Interchange Format (MIF) files representing the contents, as well as XML schemas and HTML and Excel expressions of the designs.

As shown in the diagram, the generator is made up of three primary stages that serve different functions and have different impact upon the HL7 development and publication process.

Quality Assurance and Pre-processing

The first stage in Figure B is labeled the Quality Assurance (QA) stage. In this stage, each of the source files provided to the generator is reviewed, perhaps transformed, and assembled into a set of cross-reference files from which various quality measurements can be taken.

For example, the definition of each static model in a dynamic model file (from the publication database) is documented. Simultaneously, the QA stage looks at the source files for static models and documents those models. The reference checking process, involves look at the expected content (expressed in the dynamic model files) and comparing this with the actual static model that has been provided. Any mismatches in expectations (a design for which there is no definition in a publication database or vice versa) are documented.

These quality assurance checks have been essential to the improvement over recent periods in the ballot content being produced.

Generator Source Files

The source files for the generator is a whole, and for the quality assurance stage in particular include the following:

• Vocabulary reference file -- the vocabulary content expressed in a MIF-2 file is exported from RoseTree;
• Reference representation of the Reference Information Model (RIM) This may be represented in either the idiosyncratic "rim.XML" format, or (in the near future) in the a "coremif" file (MIF-2.1.X);
• "dynamic" XML from the PubDb -- which expresses the domain content contents, and definitions for each the artifacts in the domain. These artifacts include storyboards, application roles, trigger events, interactions, static model message designs, and others;
• Static model design files from the RMIM Designer in Visio, expressed as either:
  1. Visio static model XML files; or
  2. HMD files as exported with RoseTree from the design repository;
• Source files for the HL7 datatypes specifications, both as MIF files, and as XML schemas;
• Definition of each of the expected CMET (Common Message Element Type) static model files. This CMET information is in a text file present;

QA Stage Processing

The QA stage processes these source files and builds from them a single reference identifier file of all of the content that has been provided. A separate transform processes and analyzes this reference file to produce a quality assurance report for the ballot. At present, the QA stage uses an ad-hoc representation for this file. In the near future it is hoped that this will be represented as a MIF file similar to what would be used to define and control publication content. This revised form would also be used for publishing or reference checking.

Initial MIF Transform Stage

The second stage of the V3 Generator accepts the intermediate files produced by the quality assurance stage, and builds from them two sets of artifacts.

The first of these is a complete set of MIF files based on release 1.0 of the MIF specifications. These files provide a consistent MIF-1 representation of all of the static models, dynamic specifications interactions, etc.

The second production from this stage is the construction of a "dependency tree" for the full package. The dependency tree represents, at its highest level, each of the domains being balloted. Underneath the domains, branches of the tree represent each of the topics within the domain. In turn the branches below the topics show each of the application roles, storyboards, interactions, and static files defined within the domain. Further, for each of these artifacts the tree lists the artifacts dependencies upon other artifacts. For example, an interaction artifact will show dependencies upon a trigger event, a message wrapper and a payload static model. When the complete tree is built it determines both the complete content of the ballot, shows the full extent of the expected content, as determined by the cross-references. In the future this tree should be replaced by the MIF-based for the reference check file produced and used in the QA stage.

Final Output Stage

The "final stage" of the V3 Generator is actually a set of independent output processes that use the output files of the MIF-1 Stage to assemble the "final" outputs of the generator. These include:

• A complete set of MIF-2 files which are the preferred representation for model interchange format files today;
• Complete set of XML schemas;
• HTML table views of each of the static models; and
• CSV files for use in Excel and representing the static models.

There is a near-term objective within the Tooling Work Group to make all of the final stage deliverables flow from the MIF-2 files, rather than from the MIF-1 files. Thus the schemas, table views, and Excel views would all be generated from MIF-2 source under this plan. At that point, the MIF-1 stage comes strictly an internal requirement, and it itself can be dropped in order to go directly from the source material to the MIF-2 material. This is important because, increasingly, the Tooling Work Group expects that input material to the V3 Generator will be delivered in MIF-2 form, rather than one of the predecessor forms. It is, therefore, critical that all of the output be derived solely from the MIF-2 files rather than requiring the more dated and less functional older representations.

Grouping of Tracks to Realize a Future Open Environment

In order to plot the major stages from today's tooling environment to a future tooling environment in which almost all tools are based on the MIF schemas, and are housed in a common framework such as Eclipse, it was useful to classify the existing tools and their functions into a set of paths or tracks for migration. These tracks represent both a functional sequence (as it exists today), as well as a reasonable migration sequence for that capability going forward. There are at least six major tracks. Several of these were assigned a letter to refer to the following summary of the tracks and their steps:

HL7 Publication Database (Group A)

The HL7 Publication Database which currently documents each of the artifacts defined for a particular functional domain. As noted previously the publication database enforces the HL7 methodology through the expression of required relationships in the database, required fields in the tables, and required relationships in the forms used to define the data.

In the future, the capabilities of the publication database will need to be implemented as an equivalent set of rule-based code running used to define domains, and captured and maintained in MIF files. (The publication database functionality, in today's terms, is assumed to include the export capability to the dynamic model XML files, which actually runs as a compliment of RoseTree.)

Static Model Designer (Group B)

The second major track is the Static Model Designer, currently represented by the Visio-based RMIM Designer program. At present, the output format of this tool is a combination of a Visio VSD file, and an expression of the static model from Visio in an XML format that can be transformed to MIF. Also, the current Visio process produces the clickable graphics needed for publication, and may rely upon RoseTree to save certain in a Design Repository and subsequently to export those models as HMD files. Generically, this track focuses on a graphical designer, but these inevitably contain elements of textual editors, constraint definitions, etc.

Version 3 Standards Developed Directly in XML (Group C)

This path represents the management of a set of HL7 Version 3 specifications that are currently documented in XML directly by their authors. The current XML format for these other specifications is one defined by HL7 and based upon a document type definition used by the W3C organization in publishing its standards.

Examples of documents that are maintained in this format are those that define the Version 3 Guide; the HL7 Facilitators Handbook; the specifications data types; the specifications of the Implementable Technology Specifications; etc. At present, these are all defined and maintained with a variety of XML drafting tools, and then fed directly to the publishing transforms produce a publication.

A strongly desired support for this path of submission is to provide a publication "harness" with which the developer can do local publication of the content of their file in order to assure themselves that will appear reasonably in the final ballot; and the provision of a "what you see is what you get" (WYSIWYG) editor. The requirement for such an editor arises because the MIF schemas have a very strict accreditation of what forms of "HTML markup" can be included in the textual descriptions of the specifications. It is far preferable to detect errors in this markup as it is created, rather than only discovering errors at the time of HL7 publication. This capability is needed today in the publication database, and will continue to be needed in all of the other components. Such an editor is being developed, by the National Health Service in the UK, and can probably be adapted for use in this track, when it is available.

Ballot Content Management and Quality Assurance (Group D)

This is the process of performing ballot Content Management and Quality Assurance as the ballot content is developed. This includes the notion that each domain should be able to do its own quality assurance on the content it has defined and should be able to correct that content before submitting it to headquarters. Once submitted, a further quality assurance step might be performed, as the material is being integrated with other mature from other domains.

The framework for such quality assurance testing exists in the current generator in the current publication transforms, but these have not been made available for use by the facilitators in general.

The notion that is envisaged is to provide a Facilitators Desktop which includes all of the capability use by publishing to produce the final result, and links directly to a local copy of the V3 Generator in order that the facilitator for a particular Work Group can create a direct replica of their specification right from the outset, rather than waiting until ballot preview stages or even later when the ballot opens see their final result.

Version 3 Generator (Group E)

This track represents the Version 3 Generator and its elements, most of which conform to the future technology structure envisaged, but many of which are undergoing continuing development to enhance their functional capability support of HL7. This track is assumed to include future functionality for the V3 Generator intended to support implementers, including the generation of instance examples, the support for local documentation (implementation-level documentation rather than specification-level documentation). etc. Further, it is treated as the focal point for adding additional transforms of MIF-based artifacts to meet extended needs.

Desired Tool Components (Group F)

The is a group of functions is a set of capabilities that is either not well represented in the tool suite today or is only partially implemented. These represent a set of capabilities that have general applicability and therefore are clearly needed. These include such capabilities as:

• An instance examples generator that can produce a suite of instance messages based on the published designs in order to serve as a foundation for testing;
• Validation capability to assure that static models and other designs that purport to be derived from or refined from higher-level design artifacts are indeed valid extensions and refinements of those models;
• The ability to test the conformance of a particular message or suite of messages to the specifications captured in the MIF instances;
• The ability to support code generators that can work directly from the MIF files or their derivatives schemas, etc.;
• The ability to create a Ballot Difference Display to allow voters, developers, and other reviewers to see exactly what has changed from one ballot next.

Vocabulary Model Maintenance (Group G)

This track represents Vocabulary Maintenance. The V3 standards are deeply dependent upon the HL7 Vocabulary Model. Maintenance of this model is a detailed and difficult task. Attempts to provide simplified tooling for this function have not been fully successful. The current process needs to be revised in order to make it more sustainable within the HL7 volunteer-dependent environment.

Standard Artifact Repository and Registries (Group H)

The final track represents the establishment of a Standard Artifact Repository, and the associated Registries needed to manage and document HL7 V3. The predecessors to this track included the currently operational "OID Registry", a registry for CDA implementations being developed, known requirements to enhance a Template registry, and the long-established objective of a “Standard Artifact Repository" for use in managing and documenting the HL7 The three efforts.

Diagram of Tracks and Major Steps to Future Environment

The final diagram – Figure C – is an attempt to map a series of tracks and their constituent asks that need to be undertaken to migrate from today's environment to the desired future environment. These are laid are not intended to form a “master plan”, but rather form the basis for discussion and assignment of responsibilities from which a plan can be developed.

In some cases the blobs (tasks) represent a string of inter-dependent steps. In other circumstances they may simply be a set of tasks which could be performed in parallel and merged at the very end. The diagram is discussed in detail in the following.

Initial Stage/Current State --> Final state

As might be expected, the left-hand side of the diagram represents the present circumstance – the tools as they exist today whether developed under the HL7 purview or outside of it.

The right hand side of the diagram represents the future environment in which all content is represented in MIF-based files, and the principal user interaction is drawn from an open source tooling environment such as Eclipse.

Layout of tracks

Although there is mingling of the two objectives, the primary tools used to support development within HL7 are shown in the upper portion of this diagram, whereas those tools aimed at implementers or other interested parties are shown in the lower portion of the diagram. Specific tracks include:

Publication Database Track (Group A)

The first track across the diagram represents the evolution of the existing publication database. There are two near-term improvements that should be made to the publication database, even before its functionality is migrated to MIF-based file support. Indeed, these functions will both support the future development of an Eclipse-based tool, and also will allow the transition to the future platform in a reasonable fashion. These and other tasks along this path are:

• Create a WYSIWYG editor for use wherever needed, and initially in the publication database (and other similar tools). This is a reusable component that will edit annotations for use in all of the MIF files. These annotations allow fairly rich HTML markup, but the individual editors need the ability to edit these files in a visual editor that displays the markup result as it would appear the ballot. The current PubDB uses a partial solution of this sort built upon capability in all XML-Spy.

  A more general solution is being developed by the NHS in the United Kingdom, based on Java implementations of such an editor. The task represented here is to take the Java implementation, and package it so that: it can be invoked from the publication database in Access; and the results of the editing session can be returned to that database for storage as a database element. The specifications for these component are relatively easy to represent, and it could be undertaken by anyone who is interested and or willing area

• Convert the extract from the PubDB to MIF-2, from the current idiosyncratic XML format. This could be done one of two ways. First, the expression engine (currently RoseTree) could be modified to produce MIF files, rather than the idiosyncratic XML DTD. This has the partial advantage that the data structures used to produce the extracts would be identical for the two products. A second alternative would be to simply transform the idiosyncratic XML to MIF-2. This could be done outside of and downstream from the publication DB extract.
• Produce valid publications from MIF-2 format, this stage in the evolution of the publication database is a requirement for final migration to any new tool. This step is dependent upon the prior step (having a MIF-2 extract). It allows the Publishing Work Group, and its XSL contractor to revise the existing ballot-generation transforms to work off of MIF-2 content, rather than the current dynamic model XML content.

  This step must be completed before any conversion away from the publication database can be undertaken, since the future tool will almost certainly speak only MIF-2 as its lingua franca, and thus we will need to have a new publishing process in place before we change the source.

• Migration of the PubDb Functionality to Eclipse The final step on this path would be to move the publication database functions -- in particular their enforcement of the methodology rules -- to a Java or other Eclipse-enabled application environment. The initial implementation of this environment would be predicated on the availability of MIF-2 files for each of the existing HL7 domains. These would then be the source file for further evolution of each topic area. Independent development of new content could begin with the new applications at any time.

  Since the existing PubDB provides pretty good documentation of the rule-enforcement requirements for this tool, and because the forms in the existing publication database represent the content that is needed, the current database could serve as a reasonable requirements pattern of development and tool.

  Additional features that have been desired in this new tool include the ability to do "cascading" of model documentation. This is the concept that the definition for a constrained attribute (for example) in an RMIM could be documented at the top level, and the modified description could then be used in each of the derived functions until such point as a designer wishes to modify the description. In that case, the modified description would be propagated to subsequent implementations. This allows the reuse of documentation throughout a domain and indeed throughout HL7, and would allow for more expressive documentation at each stage of the process.

Static Model Designer Track (Group B)

The third row represents the evolution of the static model designer (currently within HL7 using the Visio-based tools) to an open source static model designer based on Eclipse under OHT’s framework. There is currently an active and advanced project under sponsorship by the NHS in the United Kingdom to undertake this migration. There is every expectation that this process will succeed and will result in the complete migration of static model design functions from Visio to the new environment. That having been said, there are a number of supporting tasks to this effort that need to be undertaken within the HL7-supported framework these include the following subtasks:

• Testing of the new static model designer at each stage to ensure that it meets the expected requirements of the existing HL7 users and of future implementation users;
• Document additional functional requirements that may be required to support the definition of Templates to be applied to static models.
• Production of documentation for use within HL7, perhaps as an extension to or perhaps as a replacement for documentation provided by the NHS project team;
• Education to be provided for all prospective users of this tool. In particular, there needs to be a block of education provided to HL7 facilitators who will be required to move their work from the old tools.

  This needs to be planned and executed in collaboration with the Tooling Work Group, the Publishing Work Group, and the Education Work Group.

Establishment of a WYSIWYG Editor (Component) for Annotations (Group C)

The fourth line in the diagram represents an element discussed previously both with respect to the publication database, and with respect to tooling general. This is the creation of a generic editor for MIF annotations. Such a component would give us the ability to transfer all of the existing XML-based content into MIF-2, and provide a tool to the individual Work Groups for maintaining these specifications in MIF-2. This is needed for the so-called "other" specifications that currently exist in the Version 3 environment.

Facilitators/Publishers Desktop (Group D)

The fifth row in the document is shown as single "blob", because it represents efforts that will be going on within the Publishing Work Group to advance its content and dependencies from the current environment to the future. It is labeled generically as the Facilitators/Publishers Desktop. It represents the capability (outlined earlier) for a domain facilitator to create, generate and publish its entire content, easily in their local environment. The desktop will also provide the ability to perform quality assurance on the content being represented and to report any quality errors detected to the facilitator.

Finally, we wish to undertake in the near term continued evolution of the publishing process from simple file submissions to file submissions through a version control system such as the current SVN system. The notion here is that each work group will version their content for their own purposes, and then let publishing know the "tag" that designates the content to be published in a ballot, so that a set of automated processes can be created to capture that tagged and use it to build the next ballot. The principal individuals who may be involved in such an effort include, George Beeler, Michael Krot (HL7’s XSLT contractor) and Don Lloyd.

V3 Generator Track (Group E)

The second row of the diagram represents extensions to the V3 Generator, cast as two tasks:

• The primary task is a single effort (although built of multiple sub-tasks) to migrate the V3 Generator from dependence upon the idiosyncratic XML formats of today to a single input dependence on MIF-2 files. Although the generator itself may be the source of these MIF-2 files, it is important that, in the near term, all of the generator output files can be traced back to a MIF-2, rather than to one of the intermediate products of the generator such as MIF-1. When this is done, it will possible then to remove any single idiosyncratic form of source file and replaced it with the appropriate MIF-2 representation.
• The follow-on task is to look at new requirements for transformation, such as may be required to define and apply Templates defined for CDA implementations, and extend the “generation” capabilities to address these.

Lloyd McKenzie has recently begun to develop a series of "improvements" to the existing generator, which include the transfer of some of the file dependency to MIF-2 files. It's entirely feasible that this project could be done collaboratively between volunteer effort and some of the work being done for publishing (cited below).

General Functions for HL7 and Implementers (Group F)

Finally, at the bottom of the diagram we discussed a number of functions that should be incorporated into the tooling environment. Many of these may be extensions to the V3 Generator, but others will need the support of a full graphic user interface (GUI), and therefore should be built on the eclipse framework. The functions that are included in this class include:

• An instance example generator. The current one, included as a part of the Instance Editor very good, but it needs further documentation, and perhaps usability improvements in order for it to be adopted for use in Hl7 balloting;
• Static model refinement – is the process of refining or further constraining static models for use in a particular localization (whether at the level of an affiliate, or the level of an individual project). Certainly, this can be done with the new Static Model Designer, but there is probably also a requirement to allow editing these MIF-based designs in a "tabular" format where one can see multiple dependencies on a row, can alter individual cells and have those be reflected with appropriate validation in the MIF file.
• Model Validation and Testing for appropriate constraints and refinement from the RIM, Vocabulary and intermediate static models. To accomplish this, there are variety of tools that are needed to be implemented and exposed for easy use on the Eclipse desktop. These include the ability to do MIF file differencing (MIF-DIFF); validation against Schematron rules; assurance that the refinement rules have been appropriately followed; crosschecking changes against the Implementation Technology Specification, and Vocabulary Specifications, etc. Many of these tools are under development within the NHS and CHI, and there is some reason to expect that perhaps this is an area that one could simply observe and foster, without having to fully support.
• A Generalized ANT desktop. The ANT-based products currently in use (V3 Generator and the Publishing framework) are highly functional, but they are executed entirely by launching a series of command line (BAT file) actions. Moreover, the configuration files for these processes are edited as text files but are key parts of the process.

  It would be highly advantageous to select, tailor and document an ANT desktop to support editing the configuration files, linking individual act targets through a GUI interface, monitoring the execution of these, etc. Such a desktop could be beneficially applied to the Facilitator's Desktop, the V3 Generator, and potentially to such things as the Example Generator and the publication database replacement. The tools currently available are "programmers tools" and are not well structured to support more general users of the Hl7 Tools.

• Provide Ballot Differencing. There is increasing need to have what is called the “ballot diff” which can amalgamate all the differences between two ballot versions. This can useful to people with varying needs such as authors, voters, implementers and Work Group management. The diff can cover various domains like (dynamic model, static models, interactions , documentation etc). Having a diff of this notations can ease QA and Quality aspects of publication where one can track changes, deletes etc.

Vocabulary Maintenance (Group G)

The tooling required for Vocabulary Maintenance has been the subject of frequent discussion within the Tooling Work Group, the Vocabulary Work Group, and related bodies.

Discussions were held during the November 2008 Harmonization Meetings about a likely direction for moving this effort. The Vocabulary Work Group has expressed a desire to see the vocabulary content maintained in a terminology service that can also be used to support other terminologies needed the end-users.

The Tooling Work Group and the Publishing Work Group feel strongly that however the content is maintained, it is essential that there be an MIF-2 path both to and from that "source of truth". This would allow the complete expression of the HL7 maintained a vocabulary in MIF-2 files for use by all of the other tools; as well as the ability to provide updates and changes to the vocabulary content from MIF-2 sourced tools.

The tasks outlined in this path are those needed to build upon prior discussions, and proceed to identify a group willing to undertake the development of such tooling, assuming appropriate support can be found. The steps are therefore:

• Define the basic requirements for vocabulary maintenance (both from the perspective of the Vocabulary Work Group, and from the perspective of Vocabulary users), and the preferred "architecture" for implementing the future "source of truth" for vocabulary. (It has long been accepted the current Access implementation in the Design Repository is not adequate for long-term use as a vocabulary repository.)
• Using the results from the preceding task, develop a Request For Proposal to build test and implement such vocabulary maintenance, and seek responses to the RFP.
• Contract for execution of the RFP
• Perform the necessary acceptance testing and integrate the new tool in the HL7 productive environments.

Develop Foundation for Standard Artifact repository and registries (Group H)

Unlike Vocabulary Maintenance, there has been less discussion, and therefore is less consensus surrounding questions of how to address the development of a Standard Artifact Repository, and what to use as the primary resource for the increasing number of "Registries" being requested of HL7. Therefore, the tasks outlined in this path are those necessary to gain consensus within HL7 on the strategy for addressing these needs. The initial steps are as follows:

• Establish the scope of this effort. It is assumed, in this document, that this includes the requirements for a Standard Artifact repository, internal registries such as the OID Registry, and user-defined repositories such as those for CDA Implementations, Templates, etc.
• Distinguish the related, but presumably distinct requirements to (a) create and maintain a standard registry for the management of HL7 "Standard Artifacts", as opposed to (b) the requirements for "Version Control" of these artifacts. The latter are critical functions for developers, the former are critical functions to allow HL7 to control and understand the developments that are ongoing.
• Seek agreement on the "preferred" platforms to be used for these registries, and the relationship of these platforms to the version control systems.
• Initiate Request for Proposal processes to obtain the necessary foundation installations for a Standard Artifacts Repository, and the necessary Registries.

GWBeeler 17:31, 11 December 2008 (UTC)