ITS Acceptance Factors

INM has an action item to create a list of sucess/acceptance requirements for an Implementable Technology Specification (ITS). The aim is not to exhaustively define the characteristics of ITSs, but to provide guidance what the most important acceptance criteria are for a new ITS to be accepted as a workitem by the Infrastructure and Messaging TC (ideally the list should not exceed 10 acceptance criteria). The basic checklist consist of:

• In general the ITS SHALL define how to represent instances of RIM objects. The primary aim of the representation is for the exchange of information between systems. It covers ISO levels 6 and 5.
• The ITS proposal must address implementation concerns, and describe how it conforms to industry best practice for use of the technology in question.
• The relationship with other HL7 ITS specifications must be described in the proposal, to help clarify when it would be appropriate to use the ITS, and whether it would replace any existing ITS specifications.
• The scope of the ITS need not extend to all RIM derived objects, its scope may be limited to a well defined subset of RIM derived models, in which case the ITS SHALL clearly identify this limitation. [Precedents: the XML ITS which doesn't support all of the constraints possible in the abstract model, or UML Release 1 ITS which describes the representation of data types, and doesn't describe the representation of structures]
• The process of creating the representation of instances of RIM objects SHALL be based solely on non-optional specifications/models that are produced by the HDF.
  • Note: If the process requires specifications/models that are not currently mandated and produced by the HDF, then those that bring forward the ITS should propose a change to the HDF. Acceptance of those changes is a requirement for the ITS to be considered as a workitem for INM. We should avoid the situation where an ITS is (partially) based on FooBar diagrams/models when those FooBar diagrams/models are not part of the standard development process for abstract models.
• The ITS SHALL maximize the preservation of the semantics of the RIM derived objects given the constraints as specified in the scope of the ITS as well as the constraints of the technology or encoding mechanism used by the ITS.
• Those that bring forward an ITS SHALL provide statements of at least 5 member organizations that they will implement the ITS within a reasonable timeframe of it being initially published.
• For non-trivial ITSs tooling will be required to transform RIM-derived models into its encoded format. A Beta version of these tools, as well as commitment to support these tools for a reasonable initial timeframe SHALL be presented to the committee jointly with the proposed ITS itself.

Notes

1. When reviewing/creating these criteria, keep in mind that they should be applicable to ITSs of varous types: the XML ITS, a (hypothetical) ER7 ITS pipe/bar ITS, a (potential) Corba or Java object ITS, the potential ASN.1 ITS, the (existing) UML Release 1 ITS, the (proposed) UML Release 2 ITS, as well as an (unlikely) clay tablet ITS. The encoded representation format may be a string, an object, or an API call.
2. The criteria will be retrospectively applied to the existing ITSs, which may lead to changes. (e.g. the XML ITS needs to document what parts of the abstract models are not supported by the XML Schema it uses as a representation).