Table of Contents | ||||||
---|---|---|---|---|---|---|
|
...
Not all openEHR classes are defined as codes, but most of them are. Most notable missing ones: ADMIN_ENTRY, HISTORY, EVENT_CONTEXT.
openEHR | ISO13606 | ||||
|
|
...
21090 class | attribute | comments |
---|---|---|
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, | 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. |
| controlActRoot, | 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:
|
| 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. |
| 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. |
...