Page Comparison

SECTION

SECTION

ENTRY

ENTRY

language

CODE_PHRASE [1]

(items)

ELEMENT

generic mapping rule:
map to an ELEMENT object with name attribute set to indicate which source model attribute and value set to a CS; then follow CODE_PHRASE -> CS rule

Can ELEMENT.name be used in this way?

encoding

CODE_PHRASE [1]

(items)

ELEMENT

generic mapping rule:
map to an ELEMENT object with name attribute set to indicate which source model attribute and value set to a CS; then follow CODE_PHRASE -> CS rule

Can ELEMENT.name be used in this way?

subject

PARTY_PROXY [1]

subject_of_information

RELATED_PARTY

rule: PARTY_PROXY->RELATED_PARTY

subject_of_information_category

CS [0..1]

proposed rule:
where subject in openEHR data is a PARTY_RELATED, the relationship can be mapped to this attribute

provider

PARTY_PROXY [0..1]

info_provider

FUNCTIONAL_ROLE

map EVENT_CONTEXT.
health_care_facility -> healthcare_facility,
setting -> setting
PARTY_PROXY.external_ref -> performer,
set function = fixed value 'provider'
mode - not recorded in openEHR

MISSING IN OPENEHR - ENTRY.mode

-

uncertainty_expressed

Boolean [1]

rule:
synthesise to False

Hard to see how this attribute could be a) on all Entries, and b) be a Boolean

CARE_ENTRY

ENTRY

protocol

ITEM_STRUCTURE

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

guideline_id

OBJECT_REF

-

INFORMATION LOST (not likely to be present in source in most cases)

ADMIN_ENTRY

ENTRY

data

ITEM_STRUCTURE

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

OBSERVATION

ENTRY

data

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

state

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

EVALUATION

ENTRY

data

ITEM_STRUCTURE

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

INSTRUCTION

ENTRY

narrative

DV_TEXT

(items)

ELEMENT

use algorithm 1 below.

expiry_time

DV_DATE_TIME

(items)

ELEMENT

use algorithm 1 below.

wf_definition

DV_PARSABLE

(items)

ELEMENT

use algorithm 1 below.

activities

List<ACTIVITY>

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

ACTIVITY

CLUSTER

description

ITEM_STRUCTURE

(itemsparts)

use algorithm 1 below.

timing

DV_PARSABLE

(itemsparts)

ELEMENT

use algorithm 1 below.

ACTION

ENTRY

time

DV_DATE_TIME

(items)

ELEMENT

use algorithm 1 below.

description

ITEM_STRUCTURE

(items)

CLUSTER/ELEMENT

use algorithm 1 below.

ism_transition

ISM_TRANSITION

(items)

CLUSTER

use algorithm 1 below.

instruction_details

INSTRUCTION_DETAILS

(items)

CLUSTER

use algorithm 1 below.

ISM_TRANSITION

CLUSTER

current_state

DV_CODED_TEXT

(itemsparts)

ELEMENT

use algorithm 1 below.

transition

DV_CODED_TEXT

(itemsparts)

ELEMENT

use algorithm 1 below.

careflow_step

DV_CODED_TEXT

(itemsparts)

ELEMENT

use algorithm 1 below.

INSTRUCTION_DETAILS

CLUSTER

instruction_id

LOCATABLE_REF

(itemsparts)

ELEMENT

use algorithm 1 below.

activity_id

String

(itemsparts)

ELEMENT

use algorithm 1 below.

wf_details

ITEM_STRUCTURE

(itemsparts)

CLUSTER/ELEMENT

use algorithm 1 below.

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.