Conformance Datatype Specialization Constraints
Data Type Specialization Constraints
this document has been superceeded by the contents of the 2006 May ballot -- where the specialisations section was included as part of the committee ballot and is being maintained via formal ballot reconcilliation
Changes since Jan 2006 ballot
Rename flavors as specializations
Add section 4.2, relationship to HL7v2 data types <fo> it seems to me that this should be added as new subsections to 5.3.1</fo>
4.1 Summary
It shall never be possible to change or create new data types, except through the formal HL7 ballot processes. However it is possible to define data type specializations that can be referenced in profiles and instances. The way that this is done is described in this section.
HL7 Version 3 data type specializations are localized constraints that restrict data types, resulting in data types which are applicable to a specific region, project or other localization. This section documents the requirements for these constraints, and discusses methods to assert their use in models and instances.
4.2 Relationship to HL7v2 data type constraints
HL7v3 data type specialisations represent "re-usable" constraints, which is something v2 did not support. At the same time, HL7v3 data types have behaviours which makes the drill-down constraint process unmanagable. With many v3 data types you can drill down to infinite depth rather than being limited to "sub-components" as you are with HL7v2.
4.2 Requirements for providing specializations of HL7 data types
4.2.1 Definitions
Data type Specializations are localized constraints that can be used to restrict HL7 data type definitions in specific HL7 Contexts. For example, AD.UK.BSI7766 might be a constrained subset (specialization) of the HL7 address data type (AD) that applies the rules defined in BSI standard 7766 to localize addresses that are to be used within the UK. Such a specialization may be defined within a package balloted by the HL7UK affiliate, and referenced by specifications approved by that affiliate, and message profiles produced for use in the UK.
Data type Specializations may be flagged as ‘abstract’ and where this is the case they cannot be used in message instances. Abstract data type specializations refine an HL7 data type for use within a specific application and/or context. Abstract data type specializations are always based on one normative HL7 data type. An abstract data type specialization can be used to group a set of choices based on different data types, providing that all of the choices are valid refinements of the grouping specialization ( The grouping specialization can be a refinement of the general purpose HL7 ANY data type that identifies the full set of HL7 data types). While abstract data type specializations may not be referenced in the instances, they may be included in model specifications to constraint the type of a RIM attribute.
A concrete data type specialization identifies a model that can be used to validate instance of a localized model. A concrete data type is a refinement of a single HL7 data type. A concrete data type may be, but need not be, a refinement of an abstract data type specialization. Where a concrete data type specialization is a refinement of an abstract data type specialization it identifies which member of the set of choices permitted by the abstract data type has been/should be used to validate the component. Only concrete data types can be referenced in the specializations attribute of an instance.
4.2.2 Detailed Requirements
1. It must be possible to express in a message instance that a named data type specialization MAY be used by the receiver to validate the contents of the RM attribute.
To ensure international interoperability the names of specializations which are not defined in the abstract data types specification should not replace the base data type for a RIM attribute where this is communicated in an instance, but may be sent in addition to this. The base data type is communicated in a way that is determined by the ITS, and for the XML ITS, this is achieved using the XML attribute “xsi:type”.
Example: xsi:type=”AD” typeSpecialization=”AD.UK.BSI7766”
2. It must be possible to package sets of related data type specializations.
Data type specializations can be defined at different levels, such as:
- By HL7 (within the Abstract Data Type Specification)
- National/regional HL7 Organizations
- Specific national/regional projects.
Packages which contain data type specializations should be able to clearly identify the relationship between data type specializations they define and those defined by a higher-level body.
Example: In UK, addresses used in the healthcare context could be defined using a specialization identified as AD.UK.BSI7766 while in the Australian addresses could be defined as AS4819address, both being specializations of the HL7 defined data type AD
3. It must be possible to maintain packages of data type specializations for each HL7 context.
Where two or more contexts define data type specializations with matching sets of constraints then the creation of a standard data type specialization within the abstract data types specification, a universal context package, or an affiliate balloted package should be considered..
Example: If CS.UK.UserTypes and CS.FI.UserTypes were identical the appropriate HL7 committee would create a UserTypes specialization and, after a suitable period for the retirement of the context-specific types, should deprecate the use of the context-specific specializations.
4. It must be possible to define more than one data type specialization for each underlying HL7 data type.
Example: See multiple specializations of the AD data type illustrated above.
5. A datatype specialization may be defined as a choice of other specializations and/or base data types. All options within the choice must be valid refinements of the parent data type of the specialization.
Example: ShortString and ResultCodes could be defined as speciaizations of ST and CV respectively, with LabResult (a specialization of ANY) being defined as a choice of ShortString, ResultCodes, and INT.
6. Where a static model allows more than one data type specialization to be used for a particular RIM attribute, the data type specialization against which the value could be validated by the receiver may be expressed in the instance. This is done by supplying the data type specialization name in the “typeSpecialization” property of the datatype ANY.
7. More than one data type specialization may be asserted in the instance for each RIM attribute. The ”typeSpecialization” property can take a list of values, which must be the names of concrete data type specializations.
8. Data type specializations may be defined as restrictions of basic types, generic types, or fully expanded generic types. not be independently parameterized and all generic types shall be fully expanded in the specialization definition.
Example: If an interval needs to be constrained through a specialization, it may be fully specified as IVL_TSComplete, rather than a specialization of the generic type IVL being defined. Alternatively a specialization IVLcomplete may be defined that requires a high and low component, and the type IVLcomplete<TS> be used in the model specification.
9. It must be possible to use a named data type specialization as specified in the static model or the instance with a standard validation tool to validate conformance. This is a design principle for this specification, and a criteria that should be followed when evaluating changes for future versions of the document, as well as by authors of data type specialization specifications. The requirement applies to instance validation in any approved ITS at the time that a specification is produced.
10. The following table contains the information items to be included in a data type specialization specification. It does not mandate the format of such a specification, which is to be determined elsewhere, and in the absense of other direction from HL7 is at the discretion of the publishers of such specifications.
Addition to the conformance statement section (new 4.3)
| name/title | A name expressed as a plain text human readable title. | M |
| Formal name | The formal name must be unique within the context of the package that contains the definition of the data type specialization.It is the responsibility of the author of the package to ensure that unique formal names are assigned to data type specializations defined within the package. Tooling support for this may be available. | M |
| Description | A textual description of the content and usage of this data type specialization. | M |
| Specification | Tabular specification covering each sub-element as a row with cardinality, value refinements etc. | M |
| Schema | Schema fragment for this specialization. NOTE: In practice this is required if the data type specialization is to be used with the XML ITS because the data types schemas published by HL7 alongside the XML ITS are not generated directly from the abstract data types specification. | O |
| Example | An instance example using the XML ITS conforming to the schema fragment. | M |
| Rationale | Description of the reason for specifying this as a separate data type specialization. For example, to conform to UK NHS Data Dictionary. | O |
| HL7 derivation | The base balloted HL7 data type with which all instances of this specialization conform. | M |
| Specialization derivation | Other data type specializations of which this is known to be a valid refinement. For example, a coded specialization that requires a single translation may be a refinement of one that allows one or two translations. | O |
| Other derivation | References to other sources or specifications that this (e.g. in the UK the relevant NHS Data Standard). | O |
| Substitutability | Specific indication of other data type specializations that can be used in substitution for this one. | O |
| Version | A version number. It is assumed that versioning will apply to a package of data type specializations rather than individually. Thus the formal name will not change but the version number and unique ID will change. Propagation to data type schemas and message specifications will be based on a given version of a package of data type specializations. | M |
| History | A log of changes to this data type. Until and unless changes are made this will just be its creation date. | M |
| Is abstract? | A flag indicating whether the specialization may not be referenced within an instance | M |
Issues
Should the use of Generic types in specializations be supported in the same way as regular types, so that specializations of the generics can be defined and used in combination with specializations of the base types. This specification assumes so, but it was not clear what the intention of the draft for comment document was in this area.
