Re: [ubl-clsc] UK Gov Codelist Requirements

[Burnsmarty@aol.com]

Paul,

 

I believe we have alrady captured these requirements as noted below. Please see if there needs to be a change in wording to make this clearer.

 

Hope this helps,

Marty

 

In a message dated 1/28/2004 3:25:31 PM Eastern Standard Time, paul.spencer@boynings.co.uk writes:

As requested at today's telecon, these are the requirements extracted from
my position paper on codelists that was recently uploaded.

Support long-term archiving of documents
----------------------------------------
Many documents require long-term archiving. To achieve this, the documents
must be able to indicate the version of a code set that is in use. They
should do this both in the code list reference in the instance document (so
the correct set is accessed) and in any document metadata (so that the code
list(s) required can be archived with the document).

1.1.1   [R32] Support for describing the past and future time-variance of the values

An effective date and expiration date should be established so that the code list can be scoped in time. See, for example, “Patterns for things that change with time”, http://martinfowler.com/ap2/timeNarrative.html

Versioning
----------
A code list must indicate its version number. It may also provide dates
between which it is valid. A reference to a code list must indicate the
version to which it refers.

1.1.1   [R17] Code lists must be unambiguously identified

(1) - any two uses of the same URI represent the use of the very same code list definition

(2) - no two differing code list definitions shall be represented by the same URI

The business issue is that when two trading partners identify the use  of a code list, there must not be any ambiguity.  Should either partner create a code list or change an existing code list, the identification of the resulting code list must be distinct from that of its origin.

Looking up Code Meanings
------------------------
It must be possible to find the meaning of any code in the code set.

1.1.1   [R25] Documentation for individual values of a code list

Each code value on the code list must not only contain valid values and decode values, but must also contain a long description which describes, in detail, the business meaning and usage for this code value.

Multiple definitions (e.g. short and long)
------------------------------------------
The mechanism used for holding code sets must support multiple definitions.
Specifically, it must be possible to hold both a short description, a long
description and a symbol (with information on the correct positioning of the
symbol relative to the value).

1.1.1   [R30] Support for users to attach their own metadata to a code list

Each code list must have the flexibility to have additional descriptive information added by an individual user to account for unique business requirements.

1.1.2   [R31] Support for users to attached their own metadata to individual values of a code list

Each code value must have the flexibility to have additional descriptive information added by an individual user to account for unique business requirements.

Multi-lingual
-------------
The mechanism used for holding code sets must support extracting information
in multiple languages.

Perhaps not a perfect fit for this, but the following requirement facilitates: [R30] and [R31].

Must be able to carry both a code and (optional) value in the message
---------------------------------------------------------------------
A requirement in the health service (and possibly elsewhere) is that both a
code and a meaning can be carried in a document. As an example of the use of
this, if a person selects a value from a drop-down list on a web page, the
text selected as well as a code describing it must be transmitted to health
systems for audit purposes, even though the receiving application might
ignore the text and use the indicated code list to look up a meaning.

I think this is covered by [R25] above or in the usage of code lists in

1.1.1   [R1] First-order business information entities

As first-order business information entities (BIEs). For example, one property of an address might be a code indicating the country.  This information appears in an element, according to the Naming and Design Rules specification [NDR]. For example, in XML a country code might appear as:

<Country>UK</Country>

1.1.2   [R2] Second-order business information entities

As second-order information that qualifies some other BIE. For example, any information of the Amount core component type must have a supplementary component (metadata) indicating the currency code. For example, in XML a currency code might appear as an attribute:

<Currency code=”EUR”>2456,000</Country>

These are the main requirements, and so the most important part. The rest of
the document goes into detail including proposing a syntax.

Regards

Paul Spencer
Director
Boynings Consulting Ltd
http://www.boynings.co.uk