Page Comparison

HXIT

21090 spec: Because of the way that the types are defined, a number of attributes of the data types have values with a type derived from HXIT. In these cases the HXIT attributes are constrained to null. The only case where the HXIT attributes are allowed within a data type is on items in a collection (DSET, LIST, BAG, HIST).

validTimeLow,
validTimeHigh

GG: Intended for when a receiver system assembles a structure, but one of the pieces of data comes from somewhere else and is subject to separate life-cycle management - a piece of foreign data. So your own version management/life cycle stuff doesn't apply, but it's state is of sufficient interest to know this. (it's somewhat unusual, therefore, because most data is either handled in system, or its state is not tracked at all) So yes, the normal cycle is not respected (in the local context), but the data is of sufficient interest to track that state from where is is respected (elsewhere) a little.
RECOMMENDATION: not directly needed in 13606 profile, but if encountered, may be mapped to some higher level EHR structure attributes?

controlActRoot,
controlActExtension

The idea is that GUIDs would be generated for specific events - like measuring a person's BP. Or the BP being a certain value at a certain time - by some systems, and then used to refer to those events later on. This is a referent-tracking idea See Ceusters et al.

ANY

nullFlavor

Mostly maps to ELEMENT.nullflavour. Exceptions:

• on translations of ED, CD, and PQ. But only on CD does it matter. You just swallow that equivalent into the terminology service, so you don't need to map it, only when you convert from DV_CODED_TEXT or whatever, you need to consult the terminology service to decide whether to put a nullFlavor on the translations.
  Use case: if a single coded value is given in multiple different coding systems, some coding system translations may have different coding outcomes, and therefore in CD they get their own nullFlavor.
• Name and address parts; should be mappable to openEHR ELEMENT.null_flavour based on archetypes; in 13606???
• on the bounds of intervals - straight forward mapping to INTERVAL.upper_bounded etc

updateMode

RECOMMENDATION: eleminate from 13606 profile

flavorId

RECOMMENDATION: should not be in model; eleminate from 13606 profile

QTY

expression

Was designed for representing a prescription dose dependent on external factors (e.g. patient peak flow rate, for an asthma drug). Should not really be on QTY.
RECOMMENDATION: remove in all circumstances except prescriptions. HOW TO DETECT THIS???

uncertainty, uncertaintyType

Appears also to relate only to specific uses of certain kinds of QTY. Could be mappable to openEHR precision and accuracy in some cases. In openEHR, 'uncertainty' is a concept associated with assessments, diagnoses etc.

originalText

TB: this is a contextual idea that assumes a data entry application situation. The problem is that all kinds of ways of entering data are possible: it could be chosen from a dropdown or tree widget, or be a dial widget, calendar picker, or any one of a myriad of modern GUI entry mechanisms. So I don't see how this field can be meaningfully populated in many source systems anyway; I also don't see what to do with the value of the field if it doesn't match teh stringified version of the data item, e.g. what if this field value is '11/10/2009' and the actual value string is '2009-10-11' - then it is purely duplicate information and of no use; what if the value string is '2009-11-10'? We assume then a US-style interface, but otherwise it is still a duplicate.
RECOMMENDATION: probably remove from 13606 profile.