Datatypes R2 Issue 98

Introduction

At the moment, CE disallows qualifiers in the root, but not in translations. The idea is that the root code is always the "approved" code and that translations represent the original or other translations. Because the original or translations might need qualifiers they are supported.

There are two issues with this:

1. 1. However, the primary purpose of CE is for the convenience of use-cases where qualifiers are either not necessary or are not supported by the systems using the datatype. Disallowing qualifiers for the root but requiring their use in translations forces applications to support qualifiers when they support the datatype, whether they're allowed in the root or not.

1. 2. The root CANNOT always contain the 'preferred' code because a single instance may comply with multiple realms and/or multiple templates, each of which might define a different expectation for what value-set is 'preferred'. Every application will thus need to scan through the set of available codes (root and tranlsations) to find the one that fits a given specification against which the instance is being validated. This means that constraining the root doesn't mean you're constraining the preferred code, you're simply constraining one code among many. Doing so doesn't make sense

Discussion

If there is no agreement to remove qualifiers from all CE translations, then the CE type itself should be dropped, as it fulfills no purpose.

Disposition for R2 ballot 1: CE is a flavor. Make a new flavor CE.None, that expresses Lloyd's constraints. Add a balloters note seeking submission, schedule this for resolution in Atlanta --GrahameGrieve 22:33, 20 June 2007 (CDT)

Comments by Email from David Markwell

I think that CE is a broken datatype for the following reasons:

1. As soon as you permit translations you raise the possibility that the target scheme requires qualifiers to express the meaning in the root. 2. When you constrain a coded attribute in a way that requires use of ONE particular coding scheme AND also allow translations you are saying:-

• Either the root or one of its translations must be expressed using

the chosen scheme

3. There is a problem if (as in many clinical communications) you wish to enable the original coded representation to be conveyed while also requiring that this either be CommonScheme-X or be translated into CommonScheme-X.

• In this case you know whether the required scheme requires or does

not require qualifiers but you may not know what the original coding was in and thus you have no way of knowing whether you can use CE (which as others note permits qualifiers with the CD datatype in the translation but not in the root).

4. You may in theory also specifically constrain the root if you want to say it must include representations in one or both of TWO schemes but there is a problem if either of these schemes may use qualifiers - even if the other does not. Unless you know the original scheme on all source systems is one that never uses post-coordination, the same issue applies as in point 3 5. Therefore, the only case where the CE in its current form would be useful is if for all communicating systems you KNOW that the original coding does not use qualifiers and also accept that the target MAY (or DOES) have qualifiers.

• This is probably a diminishing rare real world use case. It assumes

no originating system would use or in future migrate to the target scheme. This may not seem as odd as I suggest but it begs the question "if no one is using or is every expected to use the target scheme with qualifiers why are we requiring or even allowing translations to it?"

6. So the remaining use case for a code plus translation is where the only schemes permitted or used for the original or translations are inherently simple and cover a narrow enough domain that they do not need qualifiers. This is a use case which may exist - though not I think in the detailed clinical domain. However, this use case would have translation sub-elements that were of CE datatype and not as at present CD datatype.

As an aside there is a presumption in much of this discussion that qualifiers are difficult. It is undoubtedly true that where qualifiers are used we are dealing with more difficult meanings (i.e. more finely grained and with a degree of interconnectedness that is not found in simple areas such as gender, administrative categories, etc). However, given the a requirement to represent such meanings the idea that the alternatives to use of qualifiers are somehow simpler is a value judgement that I do not agree with. The alternatives are either a combinatorially exploded coding scheme OR splitting the meaning across attributes or classes in the model.

• In the first case (combinatorially expanded coding schemes)

translation is possible only if the source and target scheme have the same level of granularity or at least compatible models that allow a "broader" target translation to used without loss of meaning.

• In the second case translation may not be appropriate at the coded

attribute level but may instead require consideration of the whole structure (i.e. a class in the model or even a collection of related classes) since the meaning expressed in one code in SCHEME-A in a single attribute may take several in SCHEME-B.

Thus I would argue that translation is only feasible in the following cases:

• In case 6 (so simple that no coding scheme that is permitted

requires qualifiers) - for this case a simple CE that has only simple CE translations is appropriate.

• In cases where both original and translations MAY include

qualifiers. In this case the CD datatype already serves.

• Possibly in cases where a required scheme (which must be present

either as the original or a translation) the root may be CD but the translation might be constrained to CE (or even CV).

• In practice there are several potential constraints of this type

(e.g. qualifiers permitted but not qualifiers of qualifiers) and specifying an exhaustive set is probably unhelpful. A better approach would be to allow datatype constraints at design time (aka datatype flavors).

Links

Back to Data Types R2 issues