New ITS December draft

• This is a wiki-converted version of the word document, to help with harvesting of text
• A link to the full word document should be added

Table of Contents

[1 Introduction 2-] [1.1 Purpose 2-] [1.2 Summary 2-] [2 Addressing implementation requirements 4-] [3 Representing RIM objects 5-] [3.1 Overview of data types differences from XML ITS R1 5-] [3.2 Generic Serialization Models 5-] [3.2.1 The mechanics of serialization 6-] [3.2.2 Serialization Model Annotation Rules 7-] [3.3 Model-based validation 8-] [3.4 Providing alternative views of RIM-Based Models 8-] [3.4.1 UML views of RIM-based Models 8-] [3.4.2 Simplified views 9-] [3.4.3 Representing simplified data type classes 11-] [3.4.4 Semantic effects of simplifying 11-] [4 Glossary 12-] [5 Outstanding Issues 12-] [Appendices 13-] [A. Supporting HL7 member organizations 13-] [B. Tooling 13-] [B.1 The RMIM Reshaper Tool 13-] [C. Model Annotation Syntax 18-]

= Introduction=

Purpose

This document is intended to be a first draft of an HL7 V3 ITS specification. It does not repeat sections that would need to be taken from the XML ITS specification, or from the datatypes documentation that is provided alongside it.

Summary

This specification describes the method for creating HL7 implementation models using UML diagrams, XML schema, and (when desired) mappings between an alternative view of a message model and its \’parent\’ RIM-Based Model (e.g. RMIM).

It uses the same mechanisms to deliver two very different XML representations of RIM-based information structures:

• Stable, more consistent serialization using generic patterns such as Clinical Statement for the XML element names. This builds on the success of the stability of the CDA approach to serialization.
• Reshaped structures where a RIM-based model (e.g. RMIM) is \’simplified\’ to meet an implementer view requirement (e.g. mapping to local data models or supporting domain expert review).

The purposes of the new HL7 implementation models include:

• Providing a stable and consistent serialization across different versions of the same message definition, and between closely related information structures (such as those derived from Clinical Statements, or a Pharmacy DMIM).
• Enabling clearer model-based XML serialization for HL7 messages (i.e. exposing all serialization \’rules\’ within an implementation model).
  • Note: This will require changes to the HL7 Abstract Data Types specification.
• Enabling implementers to \’simplify\’ XML message representations to support local business purposes while being able to reconstitute the appropriate HL7 \’global\’ (standard) serialization as needed. Simplification may include:
  • Creating a view of a message model using business information class names (from domain analysis models) instead of RIM-based names, for business expert review / validation of a message model.
  • \’Reshaping\’ message models to collapse classes.
  • Excluding structural data within message models classes that are not considered useful in a particular message model view (i.e. for a particular purpose).
• The use of UML-based tooling with HL7 implementation models (e.g. for viewing or for the purpose of model-based automated code generation).

A key component for accomplishing these goals involves the introduction of V3 XML Serialization Models, automatically generated from human-readable annotations on selected RIM-Based Models (RBMs). Serialization Models are intended to support consistent XML representations across HL7 V3 message types and also make the V3 XML \’rules\’ for serialization more explicit.

Serialization Models allow a message model to be serialized according to cross-message generic rules, as documented by the MIF representation of the generic Serialization Model as well as by ITS decisions documented as Serialization Model annotations.

To support message \’simplification\’, a prototype message reshaping tool has been developed and is described in Appendix B. This tool can be used both in connection with this ITS, and also to define \’intermediate XMLs\’ to help interface systems to the previous ITS, as currently recommended in the HL7 Implementation WIKI.

HL7 shall declare only one Serialization Model (SM) for any given message type to be normative. One of the RIM-based model annotations will identify which SM is to be used in its normative serialization.

Key ITS differences from the HL7 XML ITS R1:

• Changed data types (to accommodate UML representation, model-based serialization and ease of use with commercially available XML tools)
• Use of a limited number of Serialization Models as the basis for determining message wire format, in order to improve cross-message type consistency and software programming stability. (The latter is a lesson learned from the success of the CDA serialization approach.)
• The optional use of UML views of any RIM-Based Model (Reference or Domain, Constrained / Message Type or Local) or the Serialization Model for various local business purposes (e.g. \’business analyst views\’, \’local model mapping view\’).

The prototype tooling that is provided to support the proof of concept of this ITS may also provide the transforms between (new) Serialization Models and the XML ITS R1.

HL7 methodology pre-requisites for approving this ITS include:

• Approving the necessary data types changes
• Establishing and normalizing V3 Serialization Models to set the wire format rules for all HL7 message and document designs. (Note: This is likely an appropriate joint work item between INM and MnM.)
• Candidate Serialization Models include:
  • One for all clinical domains (e.g. CDA, Patient Care, Lab)
  • Medications
  • One for Administration and Finance
  • Shared Messages
• Limiting the number of Serialization Models should also increase the ease of harmonizing \[creating consistent serialization rules for\] common concepts across them (e.g. the Clinical Statement Pattern, CMETs).

Addressing implementation requirements

Implementers have found that the XML ITS R1 includes some weaknesses, such as:

• XML element names for the same concepts are different in related messages. This is a result of taking the XML element names from RMIMs (message models).
• XML element names are inconsistent across different versions of the same message. While this does make validation of individual message types easier with schema, it makes it harder to create reusable message processing code.
• Numerous changes to the data types within one ITS release. These are not confined to ITS changes. There are places where modelling changes will simplify implementation, but to maintain stability, it is important that such changes are made alongside an ITS revision
• The schemas generated produced by the (XML ITS R1) HL7 Generator tool are not ideal for the production of WSDL specifications in the form that some implementers would prefer. This is a result of the nested pattern used for wrappers, rather than the use of headers.
• A large number of fixed or defaulted data items in many message specifications. The rationale for these were not well understood by many implementers, who regarded them as error-prone overhead. The reciprocal benefit of stable XML element names was not delivered, except in the case of CDA.
• Default values are not widely used in the specifications, because of a concern that some implementations will not de-reference the specifications correctly, so the instance must directly include all significant information. This requirement that the instance can stand alone has a high cost in terms of message size, and also in an increased learning curve for implementers.

Explicit Serialization Models, particularly if expressed in an industry standard formalism such as Unified Modelling Language (UML) should be easier for implementers to understand than a narrative specification. Reducing the number of RIM-based models that form the basis for serialization rules should increase the consistency and stability of wire formats encountered within a given V3 release. Designing models specifically for the purpose of setting serialization rules may also provide the opportunity for HL7 to \’streamline\’ the information it mandates is sent \’over the wire\’ in conformant implementations (e.g. HL7 guidance to implementers related to the inclusion or exclusion of structural codes required in a V3 message instance has changed over time and is still not absolutely clear with respect to the rationale given specific implementation requirements – i.e. it may be the case that some domains require fewer \’structural / semantic\’ information in instances than others).

Maintaining a set of Serialization Models that graphically summarise schema information and support detailed annotations for implementers may also be easier for HL7 to keep up-to-date and to link with other related policies and documents (e.g. element name sorting protocols).

UML views of Serialization Models should support implementer requirements for ease of interpretation (using an industry standard model formalism) and the potential use of UML-based code generation tools.

The changes to the data types necessary to support model-based serialization should also avoid some of the hand-crafting and lack of commercial tools support experienced in XML ITS R1.

This ITS also provides a method that documents mappings between a \’simplified\’ model and its parent. This type of mapping should also support creating transforms for translating between this ITS and XML ITS R1. Such transforms may be necessary in \’hybrid\’ implementation environments.

Representing RIM objects

This section describes how this ITS depicts RIM objects. It is focused on RIM objects expected to be used in XML serializations.

Overview of data types differences from XML ITS R1

The following summarizes the most significant changes proposed to the data types. These are fully documented in the separate datatypes proposal document.

• Null flavor values are reduced in number
• An IdentifierUse attribute has been added to II
• Encapsulated Data (ED) has been restructured to be a sibling of String (ST), rather than a child
• An explicit "data" component has been added for ED
• XML attributes are used for address and name part categories rather than XML element names
• "Group" was added to Coded Data (CD) to support post coordinated SNOMED terms
• Explicit XML elements were created for sets, bags and lists

In addition, at this time there are a significant number of open data type shange proposals on the HL7 wiki. It is proposed that these be reviewed, and all those that will not be addressed in this release cycle be explicitly deferred to avoid implementer confusion.

Generic Serialization Models

This ITS proposes the development of V3 standard Generic Serialization Models, to be applied to all XML serializations HL7 messages and documents.

The creation of such models should stabilize and reduce the number of models underlying what implementers can expect to see in a V3 message or document instance.

As mentioned in Section 1, candidate Generic Serialization Models include:

• CDA / Patient Care / Clinical Statement Pattern / Lab / ?RCRIM
• Medications
• Administration / Finance
• Shared Messages

For convenience, each V3 technical committee may publish the relevant subset of the appropriate Serialization Model for a given domain.

A project team or task force with members from INM and MnM may choose to \’simplify\’ Serialization Models (compared to their parent RIM-Based Models) to some degree (e.g. excluding specific fixed / default values, or reducing the \’depth\’ / flattening some model classes as tested to be appropriate for this use).

It is recommended (subject to INM and MnM approval) that Generic Serialization Models remain normative for at least 4 years.

This ITS also provides a method that documents mappings between a \’simplified\’ model and its parent. In addition to simplifying models, this type of mapping method could also support creating transforms for translating between this ITS and XML ITS R1. Such transforms may be necessary in \’hybrid\’ implementation environments.

The mechanics of serialization

This section describes the mechanics of V3 serialization within this ITS, including identifying the Serialization Model and creating Serialization Models.

Identifying the Serialization Model

Static Model reference to Serialization Model

Each static model will be associated with a single Serialization Model. This will either be done with an annotation in the model (details to be provided), or can be inferred from its parent static model.

Instance references to Serialization Model

In the instance, the Serialization Model and version will need to be declared using new attributes.

The instance may also include references to the Standard Validation Models to which the sender is asserting conformance, as well as any locally defined Templates. The rules for when and how such references are to be included will be clarified in the V3 Templates specification. It may be that the references are inferred from the implementation contract agreement and need not be made explicit in every message instance.

Creation of Serialization Models

The Serialization Model is created directly from an appropriate RIM based model. A set of annotations as described in Section 3.2.2 may be added to the model to indicate which classes and attributes are not to be directly included in serialization instances. These annotations are included in the "notes" field as structured text, and so are visible in the human readable specifications and in the machine-readable HL7 MIF (Model Interchange Format) documents.

When not modified by the annotations, the serialization of the structures follows the XML ITS R1 structures rules with the following differences:

• • Choice structures are represented in the serialization model (and hence the instance) as an XML element (naming convention to be confirmed)
  • CMET boundaries are represented using an XML element (naming convention to be confirmed)
  • Possibly the inclusion of additional attributes to identify the Standard Validation Model (alternatively these are treated in the same way as HL7 Templates, and referenced in the templateId attribute)
  • Additional attributes at the model entry point to identify the serialization model, and to provide version information for it.

For transport and control act wrapper content, the serialization may be defined by the transport protocol. While the ITS allows for this, it leaves defining such transport specific serializations to the HL7 V3 Transport Profile documentation.

Serialization Model Annotation Rules

A set of annotations to RMIMs are proposed that describe some serialization rules. These are added in the form of textual RMIM "notes", that are saved into the MIF and can be interpreted by tools that come later in the message production process. (Ideally these serialization hints would be made in a fully graphical style, but this isn\’t achievable yet.)

Serialization rules available are Suppress a clone, RIM attribute or datatype attribute Rename a clone, RIM attribute or datatype attribute Collapse a clone into its parent

These operations can be local to the annotated clone, or can apply globally to the whole model.

An example annotation is : On a clone called ClinicalDocument: ITS:global.codeSystem.suppress;global.contextConductionInd=ccInd;ClinicalDocument=DischargeMessage

On a clone called recordTarget: ITS:recordTarget.collapse

The "ITS:" prefix indicates that this is special purpose comment. Semi-colons are used to separate multiple operations. The keywords "suppress" and "collapse" correspond to a request for that action on the attribute that comes before the dot eg recordTarget.collapse.

See Appendix C (Error! Reference source not found.) for more details on annotations.

Model-based validation

One implication of establishing Serialization Models is that message-level models (like specific document models) become constraint patterns for semantic validation (rather than the direct basis for serialization).

This means that message and document instances will need to identify the appropriate constraint pattern for validation purposes. The exact mechanism for achieving this should be found within the V3 Templates specification.

To summarize, Refined Message Information Models (RMIMs) and message types become Standard Validation Patterns useful for application-level conformance assertions. HL7 Templates remain local validation patterns that set conformance rules according to local business requirements. Note that the only difference between an HL7 Template and a Standard Validation Pattern is the fact that the latter is approved by HL7 ballot.

Providing alternative views of RIM-Based Models

UML views of RIM-based Models

One feature of this ITS is to use UML (Unified Modelling Language) as a principle design mechanism. Creating an implementation of V3 models that is based on accepted industry implementation practices should help ease some of the skills pool / learning curve challenges related to V3 implementation. Also, using UML allows for detailed practical mapping to other standards such as CEN, ISO and DICOM (e.g. at the level of data types or message specifications).

A prototype tool has been developed to translate a MIF file into XMI. Figure 1 shows a small part of a UML representation of a local RIM-based message model, as outputted from the prototype tool and viewed with a commercial UML-based tool.

Figure 1: Detail from a UML representation of a local V3 Template / RMIM (NHS Care Event Report)

Simplified views

This ITS allows implementers the option of carrying out a sequence of steps to restrict and change the shape of an HL7 RIM-Based Model (e.g. RMIM) to suit various local business purposes. These optional steps may be taken with the intention of making the model easier for domain experts to understand, or easier to map onto healthcare IT systems. Often, it may be desirable to provide a view of a message model that \’mimics\’ the domain analysis model as much as possible, in order to demonstrate the mapping or \’traceability\’ between requirements and message design models.

Alternative views may also make XML message instances based on the reshaped model smaller and easier to read than instances of the full HL7 XML ITS. Such serializations, however, would not be conformant to the V3 Standard. The use of \’simplified\’ XML message instances may only be done at the users\’ risk (and may only be appropriate by agreement within small and isolated communications scenarios which are not likely to be extended in scope in future).

Alternatively these instances can be used as a step towards implementing the standard ITS. A supplier-specific simplified model can be produced and may be targetted more easily by that supplier\’s data source. An automatic transform is then available to convert these instances to the more complex standard ITS as needed.

Any simplification steps taken to provide an alternative view of a RIM-Based Model shall be recorded as mappings between the original model and its simplified view.

A prototype RIM-Based Model \’reshaper\’ tool is available that produces the following outputs:

1. The mappings between the RIM-Based Model and its simplified alternative, in a table-like XML form (which can be read back into the tool to do further reshaping)
2. An HL7 Model Interchange Format (MIF) file defining the reshaped structure
3. An example XML message using the full HL7 XML ITS R1, with instance values input by the user
4. An exemplar XML message in the simplified XML, using the same instance values

The two exemplar XML files, simplified and \’original\’, are semantically equivalent to one another. This may be demonstrated by automatically translating from full (RIM-Based) XML ITS to simplified XML, and vice versa.

The reshaping tool, being an experimental tool built for the purposes of evaluating a range of proposals for the new ITS, has some capabilities which we now do not think are appropriate or necessary for the new ITS. These capabilities may be relevant for other purposes – notably for producing local reshaped messages as an intermediate XML along the way to XML which is conformant, either to the previous ITS or the new XML ITS.

One of these capabilities is the capability to restrict a model – a step which might normally be done in other stages of modelling, but which can also be done in the reshaping tool. The following options may be taken when restricting a RIM-Based Model :

• Restrict the minimum and maximum cardinality of any property or association to a smaller subset of the line \[0..1..\*\] (e.g \[min..max\] = \[0..1\] can be restricted to \[0..0\] or \[1..1\] )
• Constrain any leaf property (= RMIM structural attribute, or leaf property within a V3 data type) to a fixed value

The following options may be taken when simplifying a RIM-Based Model:

• Collapse any association with maximum cardinality = 1, so that the two classes at either end of the association become the same class
• Rename any class, property or association
• Remove any property with a fixed value
• Remove any property or association with minimum cardinality 0 (this is equivalent to restricting its cardinality to \[0..0\] )

(The collapse of any association with maximum cardinality = \* (unlimited) is not an option because single-valued properties of the inner merged class would become multiple-valued properties of the merged class.)

The reshaping operations can be done either on parts of the RMIM proper (i.e. on classes described in the RMIM MIF file), or on classes which represent the structure of the V3 data types (taken from the data type schema). These are called \’data type classes\’.

Representing simplified data type classes

Another capability of the reshaping tool, which goes beyond the capabilities needed for the new ITS, is the ability to restrict and reshape within V3 data types, and more generally to reshape across model boundaries.

For the purposes of the new ITS, we would not expect general restriction or reshaping within data types; we would expect to see a standard set of mappings between the data types of the previous ITS and those of the new ITS (as far as that is possible) supported by two-way translation capability provided, for instance in XSLT. For local reshaping purposes (i.e. simplified messages which do not go on the wire) more general restriction and reshaping within data types may be useful.

Semantic effects of simplifying

If only the reshaping steps allowed as above are done, then the simplified or alternative model should be semantically equivalent to a restricted RIM-based model, in the following sense:

• Any valid simplified model instance can be automatically translated to an instance of the restricted RIM-based model (which is also an instance of the full RIM-based model)
• Any valid instance of the restricted RIM-based model can be automatically translated into and instance of the simplified alternative.

The reshaping tool allows collapsing of associations with cardinality \[0..1\]. This introduces some subtle semantic issues which we may wish to keep out of any new ITS definition of messages on the wire. If, during the reshaping, any associations with cardinality \[0..1\] have been collapsed , then:

• In some cases, translation of a DAM instance to an RMIM instance may be indeterminate, in that the RMIM instance may or may not contain an instance of some class (which has no property values or further associations, so does not carry any property value information)
• Valid DAM instances must obey some constraints between the cardinality of different properties in different parts of the DAM tree.

Glossary

Standard Serialization Model Standard Validation Model

Outstanding Issues

• • Is the name of the XML element representing a choice taken from the name of the choice, or from the association role name?
  • Are names for entry points into CMETs generated from both the association and the root class name as is is the case in the current ITS?
  • What mechanism for informal extensions is to be followed – that used by Gunther in SPL, that specifed in the XML IST R1, or both
  • Are the identifiers for the Standard Validation Model conveyed in the templateId, or in a different attribute.
  • Are Standard validation Models referenced everywhere in the instance, just at model entry points, or are they inferred from the interactionId?
  • Which of the datatypes changes proposed on the HL7 Wiki have been implemented in the R2 datatypes proposal that is associated with this document?

A. Supporting HL7 member organizations

(at least 5 willing to implement within a \’reasonable timeframe\’

The following organizations are willing (as at <date>) to implement this ITS, either as early (pre-standard) adopters or standard adopters:

B. Tooling

(beta tools must be presented along with the proposal) – \[LS: assume this is for final standard vote and not necessarily for first DSTU?\]

B.1 The RMIM Reshaper Tool

This appendix describes:

• What the reshaping tool does
• Tests made with it during the course of this investigation
• How the tool relates to the proposed new ITS
• Other uses of the tool
• Its current and expected future status.

What the Reshaping Tool Does

The reshaping tool is a standalone Java program whose main input is a MIF file defining a RIM-based model, typically an RMIM for a message. Supporting CMET MIFs and a data type schema are also required as inputs.

Under user control, the tool can then do any of the restricting and reshaping operations described in the paper above. Restriction operations include restricting the cardinalities of attributes and associations. Reshaping operations include:

• Renaming classes, attributes or associations
• \’unmapping\’ attributes or associations so they do not appear in the reshaped model
• Collapsing associations of cardinality 0..1 or 1..1, so the classes at either end of the association merge (and automatically renaming attributes and associations to avoid any clashes)

Throughout these operations the tool gives the user a tabular view of the reshaped model, one table per class. This display is shown below.

Most reshaping operations are local, on a selected attribute or association, but there are a few global reshaping operations which operate across the whole model.

Throughout these operations, the tool keeps track of a set of mappings between the original RIM-based model and the reshaped model. These mappings can be exported from the tool in a simple XML-based form, and re-imported into the tool for further reshaping.

It is also possible in the tool to enter and store instance values for any leaf attribute of the model. These values can be used to output example messages both in the original RBM form and in reshaped form, to compare the two for size, readability, and so on.

The following outputs are directly available from the tool:

• Mappings between the original and the reshaped model
• Example messages in original and reshaped XML
• A MIF definition of the reshaped model
• Mappings in a form suitable for use by other translation tools.

It is intended to make the following outputs directly available from the tool in the near future:

• An XMI definition of the reshaped model
• XML schema for the reshaped model

The following outputs are available from other tools which will be made available in association with the reshaping tool, either as executables or as a free web service:

• XML schema for the reshaped model
• XSLT translations between the original and reshaped models, in both directions

Experiments Done with the Reshaping Tool

Although small tests have been made with other messages, the main experiment that has been done is one of unconstrained reshaping of the pharmacy ParentPrescription message, requiring only that the reshaped message should be capable of conveying all the information in two \’greenfields\’ message examples which embody the basic capability of typical pharmacy systems.

The reshaping was unconstrained in that:

• Restriction and reshaping was allowed inside V3 data types; for instance, it was allowed to collapse data type classes into their parent RMIM classes, or to reshape the same V3 data type differently in different occurrences
• Reshaping was allowed across model boundaries, for instance across CMET boundaries.
• It was allowed to collapse associations with cardinality 0..1, as well as 1..1 associations
• Attributes could be unmapped on the basis that they were known constants for the applications involved, rather than within the message definition.

Using the unconstrained reshaping, it was possible to greatly decrease the complexity of the message definition, making it into much shallower XML (nesting depth about 5, which could have been reduced further), with many fewer distinct nodes (the number of distinct XPaths to leaf nodes was reduced by a factor of about 20). Renaming was used to make the names of associations and attributes closer to obvious domain names.

This gave a message definition which was not V3 conformant, but which was easier to map onto and to translate to and from application representations. The XML was suitable as a local \’intermediate XML\’ between an application and V3, as recommended by HL7.org on the Implementation WIKI. In this case, however, the further translation between the intermediate XML and conformant V3 could be done automatically and accurately by generated XSLT, as described below.

Because the reshaping was unrestricted, it was not the sort of reshaping that one would expect TCs to make when defining message definitions in the new ITS. More limited reshaping would be expected in this case.

Instances of the reshaped XML turned out to be about 30% of the size of the instances of the full XML ITS with the same data, including the fixed attributes (e.g. RIM structural attributes).

Using the reshaping mappings in other tools, XSLT was generated to translate between the reshaped and original XML forms in either direction. This XSLT worked accurately in both directions. The time taken to translate using Saxon 8 on a medium-spec laptop was about 300 ms for a 6 Kbyte message instance.

An experiment was done, using other tools, of mapping a flat quasi-relational XML (of the kind that is can be extracted from relational databases by several tools) onto the reshaped model, and using these mappings to generate translations between the \’relational\’ XML and both the reshaped and full message definitions. These translations ran accurately.

We are currently extending the reshaping tool to be driven by annotations in a MIF file, of the form described below, rather than interactively by user commands.

Relation of the RMIM Reshaping Tool to the New ITS

We expect that if HL7 technical committees and SIGs make new ITS definitions within their domains, these definitions will be related to current ITS definitions as follows:

• At the level of DIM classes, the new definitions will be related to current ITS definitions by reshaping operations that are supported by the reshaping tool. These may include renaming, unmapping of fixed attributes, and collapsing associations ; but respecting model boundaries
• At the level of data types, the new definitions will uniformly use the new data types. Inasmuch as there is semantic equivalence between the new and old V3 data types (i.e. in the great majority of cases), it will be possible to provide standard XSLT templates to translate between the two, for use in message translations between the two ITS

The reshaping tool can therefore be used to capture the reshaping mappings, driven by model annotations defined by TCs or SIGs. Outputs from the tool can be used to generate automatic and accurate XSLT translations in both directions between the two ITS.

These XSLT translations could therefore support full interoperability between new and old ITS, allowing systems using new and old ITS to communicate with one another, and so allowing implementors and suppliers to transition between the two ITS in an incremental manner at a time which suits them, rather than requiring any \’big bang\’ cutover.

We expect that the reshaping operations used by TCs at the DIM level will not be as radical as those used in our experiments – because the TCs have built these models to support a wide range of use cases, and they must continue to do so. Therefore the size and shape of new ITS models may differ from the current models, but not radically.

Certain associations involving Participations and ActRelationships can always be collapsed. RIM structural attributes can be unmapped and so removed if wanted. Therefore models can be flattened to some extent, but the number of attributes will not be not reduced by a great deal.

Other Uses of the Reshaping Tool

While TCs may not want to reshape their models radically in the new ITS, individual applications or groups of applications may have more restricted needs, and so more radical reshaping may be appropriate for them – for instance, restricting before reshaping, reshaping data types, and reshaping across model boundaries. Unconstrained reshaping can give much simpler models, which are easier to map onto applications or other standards. With constrained reshaping, there is greater freedom to make a message model resemble a domain analysis model.

The main use case we envisage is to use the reshaping tool to generate simpler intermediate XMLs to map onto, then using the XSLT translation capability to translate to and from full V3 (whether of the new or the proposed new ITS). This is how HL7 currently recommends applications should be interfaced to V3.

As an example, the V2-V3 mapping tool currently maps V2 messages direct onto a V3 RMIM, and there are related facilities to do V2-V3 translations from the mappings. It would be possible, using the reshaping tool, to define restricted and reshaped versions of the V3 messages, which are closer to the capability of V2 and thus simpler, and then to map V2 onto the reshaped definitions. This mapping would be simpler than a mapping direct onto V3; but by using the XSLT \’step-up\’ transformation from reshaped to full V3, V2-V3 translation could still be achieved. All the tools exist now to do this, but it has not yet been tried.

While the reshaped XML would mainly be used locally as a means of reading and writing V3, and so would not go on the wire, it would nevertheless open to groups of consenting parties to use the reshaped XML over the wire – mainly in cases where message size is important. These parties would still be able to provide conformant V3 to any other parties who required it, by using the XSLT translations.

Current and Future Status of the Reshaping Tool

The reshaping tool is currently in prototype form, having been developed for the experiments in connection with the new ITS. It is a standalone Java tool, and is not yet in the Eclipse framework. Nevertheless, it appears to be robust, so it will shortly be put on the HL7 tooling Homebase for others to try out. Some obvious enhancements are required , such as a better undo facility. At some stage it may be put on the Eclipse framework, but there are not yet definite plans to do so. It will remain freely available and will become open source if there is demand.

Generation of XSLT to translate between standard and reshaped messages is not a capability of the reshaping tool, but is done by other tools from Charteris plc, using mapping files output from the reshaper. It is Charteris\’ intention to set up a web service to provide these XSLT translations from the mappings. This web service will initially be a free beta test service, and then will be provided on reasonable commercial terms. It will always be available free to HL7 members for approved HL7 purposes – for instance, for use by TCs and SIGs to generate XSLT translations for standard reshapings.

Other related mapping tools, such as the tool used to make mappings to relational-style XML described above, will be made available on an open source basis if there is demand.

C. Model Annotation Syntax

This section advances a syntax for use as text comments on an RIM-based diagram. These are inserted by the user and picked up, via the MIF, by the Reshaping tool.

The annotations permitted are

• Suppress

attribute.suppress attribute.dataTypeAttribute.suppress eg code.codeSystem.suppress would remove the codeSystem datatype attribute from the annotated clone\’s code attribute. ("clone" being a diagram element derived from the RIM) .

• Rename

attribute=name clone=name eg. recordTarget=patient

• Collapse

clone.collapse eg global.codeSystem.suppress

The keyword "global" can also be used as a prefix, as in the example above, to make the change happen all over the model.

A BNF for the annotations is :

<rule> ::= "ITS:" <commandList> <commandList> ::= <command> \| <command> ";" <commandList> <command> ::= <identifier> "." <action> \| <identifier> "=" <name> <action> ::= "suppress" \| "collapse" <identifier> ::= "global" "." <localIdentifier> \| <localIdentifier> <localIdentifier> ::= <RIMClone> \| <RIMAttribute> <RIMAttribute> ::= <RIMAttributeName> \| <RIMAttributeName> "." <dataTypeAttribute>

Symbols undefined above :

<name> the new name for a renamed item <RIMClone> the "clone name" of an RMIM shape, cloned from the RIM <RIMAttributeName> the name of a RIM attribute of a clone eg. id, effectiveTime <dataTypeAttribute> the name of a datatype attribute eg. extension, codeSystem

All white space is insignificant.

= = Example annotations :

Note: In creating this ITS markup language, user readability was the primary aim. Ideally a fully graphical interface and presentation would be used instead of a textual one. This language was designed to suit the non technical user, hence the intuitive syntax of "=" to give an alternate name, and the english-like ";" to split multiple phrases. "Dot notation" eg patient.id is assumed to be widely enough recognised to be suitable for use.