Page Comparison

Table of Contents

maxLevel	3
indent	20px
style	disc

...

openEHR class	attribute	type	13606 class	attribute	type	description	exceptions / ambiguities
PATHABLE			RECORD_COMPONENT
	parent (not persisted)	PATHABLE		orig_parent_ref	II [0..1]	rule: generate openEHR URI	see mismatches below
LOCATABLE			RECORD_COMPONENT
	uid	UID_BASED_ID [0..1]		rc_id	II [1]	rule: generate openEHR URI	see mismatches below
	archetype_node_id	String [1]		archetype_id	String [0..1] /dt:II	rule: String id->II
	name	DV_TEXT [1]		name	TEXT [1] /dt:CD>CV	rule: DV_TEXT -> TEXT	what are possible name values?
	archetype_details	ARCHETYPED [0..1]
	feeder_audit	FEEDER_AUDIT [0..1]		feeder_audit	AUDIT_INFO [0..1]	rule: follow link & map
	links	Set<LINK> [0..1]		links	Set<LINK> [0..1]	rule: 1:1 iteration
	-			sensitivity	Integer [0..1] /rc:Sensitivity		MISSING IN OPENEHR - could either be on LOCATABLE or on COMPOSITION
				policy_ids	SET<II>		In openEHR, these settings are in the ACCESS_CONTROL object

AUDIT_DETAILS			AUDIT_INFO
	system_id	String [1]		ehr_system	II [1]	rule: String id->II	which system id is being used here?
	committer	PARTY_PROXY [1]		committer	II [1]		which user id is being used here?
	time_committed	DV_DATE_TIME [1]		time_committed	TS [1]	rule: DV_DATE_TIME->TS
	change_type	DV_CODED_TEXT [1]		reason_for_revision	CV [0..1] /dt:CD.CV	rule: DV_CODED_TEXT->CV
	description	DV_TEXT [0..1]		-			LOST INFORMATION [low importance]
+VERSION	lifecycle_state	DV_CODED_TEXT [1]		version_status	CS [0..1] /rc:VersionStatus	rule: DV_CODED_TEXT->CS
+VERSION	preceding_version_id	OBJECT_VERSION_ID[1]		previous_version	II [0..1]	rule: OBJECT_VERSION_ID->II
+VERSION	owner_id	HIER_OBJECT_ID [1]		version_set_id	II [0..1]	rule: HIER_OBJECT_ID->II
PARTY_PROXY			RELATED_PARTY
	external_ref	PARTY_REF [0..1]		party	II [0..1]	rule: OBJECT_REF->II	LOST INFORMATION: namespace, type? [not important]
PARTY_IDENTIFIED
	name	String [0..1]	Demographics_package IDENTIFIED_HEALTHCARE _PROFESSIONAL	name	ENTITY_NAME[*]	rule: String -> ENTITY_NAME synthesis
	identifiers	List<DV_IDENTIFIER> [0..1]	Demographics_package IDENTIFIED_HEALTHCARE _PROFESSIONAL	role	HEALTHCARE_ PROFESSIONAL_ ROLE [*]	rule: for each identifier: DV_IDENTIFIER -> HEALTHCARE_ PROFESSIONAL_ ROLE
PARTY_RELATED			RELATED_PARTY
	relationship	DV_CODED_TEXT [1]		relationship	TEXT /dt:CD.CV	rule: DV_CODED_TEXT->TEXT
PARTY_SELF			RELATED_PARTY			convert to RELATED_PARTY with relationship = self?
PARTICIPATION			FUNCTIONAL_ROLE
	function	DV_TEXT [1]		function	CV [0..1]	rule: DV_CODED_TEXT->CV	LOST INFORMATION openEHR allows not only coded values; non-matches will be lost
	performer	PARTY_PROXY [1]		performer	II [1]	use rule for: PARTY_PROXY.external_ref	LOST INFORMATION some openEHR Party information will be lost; 13606 only permits single II identifier
	time	DV_INTERVAL [0..1]		-		(no mapping available)	LOST INFORMATION
	mode	DV_CODED_TEXT [1]		mode	CS [0..1]	rule: DV_CODED_TEXT->CS
( EVENT_CONTEXT)	health_care_facility	PARTY_IDENTIFIED [0..1]		healthcare_facility	II [0..1]	use rule for: PARTY_PROXY.external_ref	healthcare facility is in openEHR.EVENT_CONTEXT (since there cannot be 2 HCFs in one ENTRY)
( EVENT_CONTEXT)	setting	DV_CODED_TEXT [1]		service_setting	CV [0..1]	rule: DV_CODED_TEXT->CV	service setting is in openEHR.EVENT_CONTEXT (since there cannot be 2 types of service setting in one ENTRY)

...

openEHR class	attribute	type	13606 class	attribute	type	description	exceptions / ambiguities
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		(items)		use algorithm 1 below.
	timing	DV_PARSABLE		(items)	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		(items)	ELEMENT	use algorithm 1 below.
	transition	DV_CODED_TEXT		(items)	ELEMENT	use algorithm 1 below.
	careflow_step	DV_CODED_TEXT		(items)	ELEMENT	use algorithm 1 below.
INSTRUCTION_DETAILS			CLUSTER
	instruction_id	LOCATABLE_REF		(items)	ELEMENT	use algorithm 1 below.
	activity_id	String		(items)	ELEMENT	use algorithm 1 below.
	wf_details	ITEM_STRUCTURE		(items)	CLUSTER/ELEMENT	use algorithm 1 below.

Sub-ENTRY structures

...

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, 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.

...

This attribute is defined as follows in the ISO 13606-1 standard:

Panel

This attribute identifies one or more access control policies that specifically pertain to this RECORD_COMPONENT and which need to be communicated to the EHR Recipient to govern future access to it. The identifiers may refer to policy information included in this EHR_EXTRACT as defined in Part 4 of this standard, or to policies held in external policy servers to which the EHR Recipient has access.

From part 4:

Panel

In the 13606 Part 1 Reference Model every RECORD_COMPONENT within the EHR_EXTRACT includes an optional Policy_ID attribute to permit references to such policies to be made at any level of granularity within the EHR containment hierarchy. Every RECORD_COMPONENT may therefore reference any number of access policies or consent declarations that define the intended necessary privileges and profiles of principals (users, agents, software, devices, delegated actors etc) for future access to it.
It must be remembered that some policies may apply to particular RECORD_COMPONENTs within an EHR, whilst others may apply to the EHR as a whole.

This attribute is a good example of a refactored attribute. The intention in ISO 13606 is to mark each data node with the list of policies that apply to it. However, in an EHR system, the same information model is very unlikely to be used, for at least one very basic reason: if the policies relating to a given data item or document were to change, changes would be required to the document itself. Instead, source systems are much more likely to have a policy server that references data items using whatever internal identification system is available.

...

Panel

It is important that each RECORD_COMPONENT be uniquely and consistently identified across multiple EHR_EXTRACTS, so that references to or between them remain valid. Examples of such references are semantic links, revision and attestation. The rc_id attribute is of data type Instance Identifier (II), which incorporates an ISO OID; II is currently considered internationally to be the most appropriate data type for persistent identifiers that are required to be globally unique. It is unlikely that contemporary EHR systems will have existing primary keys or internal identifiers that correspond directly to globally-unique II instances. However, an EHR Provider system that has been issued with an organisational OID might use its internal references to construct unique local extensions to that OID and thereby construct globally-unique rc_id values.
Alternatively, it might create completely new rc_ids and retain a record of the mapping of these to each internal identifier, so that any future EHR_EXTRACTS it generates will use consistent rc_id values. It is also unlikely that an EHR Recipient system will be able to use received rc_id values as its internal primary keys for the data, since every database uses a slightly different approach to generating and using such keys. The EHR Recipient might therefore also need to keep a record of the mapping of imported rc_id values to its primary keys, so that future references to those RECORD_COMPONENTS can be appropriately matched, and it can create EHR_EXTRACTs that reapply those rc_id values to the exported data. An alternative approach is for EHR systems to explicitly store the rc_id values along with the clinical data, and treat this as part of the "payload" data and not attempt to use these also as primary keys. It should also be noted that the rc_id does not function as a primary key equivalent within an EHR_EXTRACT i.e. duplicate values of rc_id are permitted if each instance does indeed refer to the same piece of clinical data within the EHR Provider system. [emphasis added]

The key requirement here is:

...

Versions Compared

Old Version 35

New Version 36

Key

Sub-ENTRY structures